I'm guessing here, but I believe the "version number" is used to make
a directory on the production machine. Thus, older versions of the
javascript are available on the production machines under their older
version number. If there's an issue in production with the new
version, code can be redirected to use the older version that is still
in its directory.
So it probably looks like:
/100/js/<files>
/101/js/<files>
/103/js/<files>
/104/js/<files>
If something goes wrong with version 104, the admin can just tell the
machine to use version 103 instead of 104.
You're right that incrementing this version number is probably not an
issue for SVN users because they put N features in a single commit and
they update the version number once. With git, a user can put N
features in N commits and changing the version number really belongs
in each commit. This makes rebasing suck.
On Thu, Jan 19, 2012 at 2:20 PM, Carlos Martín Nieto <cmn@xxxxxxxx> wrote:
> On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:
>> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>>
>> The problem I'm running into is that whenever I change a file in a
>> directory, I have to bump up the version number in the configuration
>> file. The larger version value in the config file causes my changes
>> to be loaded over the old ones.
>
> Is this a deployment script that does this? Why can't it look at whether
> files have changed? If a feature isn't ready for production, why is it
> in a branch that gets deployed?
>
>>
>> Most of my commits are edits to a file like "foo.js" and an increment
>> to the version number in "config". Ideally, each of my features
>> should live in a single commit and I should be able to make a sequence
>> of them, each time incrementing the version number in config.
>>
>
> So if you've changed the file but don't increase the config file's
> version, it means that the change isn't ready for production? If that's
> the case, you've just implemented branches, poorly.
>
> Contrary to what apparently many people think, subversion does support
> branches. Get your team to use them.
>
>> The problem I'm running into starts with me editing version=100. I
>> create new commits where I set the version to 101, 102, 103, 104.
>> When I go to push ("git svn dcommit"), my coworkers have incremented
>> the version to 103. So, I rebase my changes, and get conflicts every
>> time because of the version number!
>
> This sounds like a race condition that the svn users might be avoiding
> by committing everything immediately. Sounds like a buggy development
> process.
>
>>
>> Is there a good way to avoid these conflicts? Is there a hook I can
>> write? Is there a change to this process that would work smoother
>> with Git and its distributed development? It's okay if the version
>> number skips numbers (e.g., jumps from 100 to 104), as long as it
>> increases.
>
> You could write a merge driver that detects this situation and writes in
> a higher number, but it's all working around the fact that it's a race
> condition.
>
> cmn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html