threads / discuss / 29403

Rebase and incrementing version numbers

Subject: Rebase and incrementing version numbers

## tl;dr

16 messages between Jan 19, 2012 and Jan 25, 2012.

replies: 15people: 10as markdown or json

Michael Nahas· Jan 19, 2012, 17:20 UTC · lore
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.

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.

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!

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.

Thanks,
Mike
demerphq· Jan 19, 2012, 18:12 UTC · re: Michael Nahas · lore

Re: Rebase and incrementing version numbers

On 19 January 2012 18:20, Michael Nahas <mike.nahas@gmail.com> wrote:
Show 23 quoted lines
> 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.
>
> 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.
>
> 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!
>
> 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.

Stop using version numbers and start using the git sha1 of the code you are using.

Yves
-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
Michael Nahas· Jan 19, 2012, 18:48 UTC · re: demerphq · lore

Re: Rebase and incrementing version numbers

On Thu, Jan 19, 2012 at 1:12 PM, demerphq <demerphq@gmail.com> wrote:
> Stop using version numbers and start using the git sha1 of the code
> you are using.
>
> Yves
1. Others in the group use SVN.
2. The version number needs to be increasing, to work with the current
process.  SHA1's are random.
3. The "git sha1" for the commit/snapshot cannot be put into the
config file, which is part of the snapshot.
Mike
PJ Weisberg· Jan 19, 2012, 19:58 UTC · re: Michael Nahas · lore

Re: Rebase and incrementing version numbers

On Thu, Jan 19, 2012 at 10:48 AM, Michael Nahas <mike.nahas@gmail.com> wrote:
Show 11 quoted lines
> On Thu, Jan 19, 2012 at 1:12 PM, demerphq <demerphq@gmail.com> wrote:
>> Stop using version numbers and start using the git sha1 of the code
>> you are using.
>>
>> Yves
>
> 1. Others in the group use SVN.
> 2. The version number needs to be increasing, to work with the current
> process.  SHA1's are random.
> 3. The "git sha1" for the commit/snapshot cannot be put into the
> config file, which is part of the snapshot.

Suggestion #1: Just put $Rev$ into the file and be done with it until the team moves over to Git (at which point you can figure something else out).

Suggestion #2: In your release process, put something like `sed -e "s/@@id@@/$(date +%s)/" source-dir/config > release-dir/config`

-PJ
Michael Nahas· Jan 19, 2012, 20:06 UTC · re: PJ Weisberg · lore

Re: Rebase and incrementing version numbers

Show 8 quoted lines
> Suggestion #1:  Just put $Rev$ into the file and be done with it until
> the team moves over to Git (at which point you can figure something
> else out).
>
> Suggestion #2:  In your release process, put something like `sed -e
> "s/@@id@@/$(date +%s)/" source-dir/config > release-dir/config`
>
> -PJ
Ideally, this value only increments with a change in a certain directory.

I think using either $Rev$ or a data+time value conditioned on a file changing in a directory might work. Thanks!

Mike
Santi Béjar· Jan 19, 2012, 23:31 UTC · re: Michael Nahas · lore

Re: Rebase and incrementing version numbers

On Thu, Jan 19, 2012 at 7:48 PM, Michael Nahas <mike.nahas@gmail.com> wrote:
Show 6 quoted lines
> On Thu, Jan 19, 2012 at 1:12 PM, demerphq <demerphq@gmail.com> wrote:
>> Stop using version numbers and start using the git sha1 of the code
>> you are using.
>>
>> Yves
>
[...]
> 2. The version number needs to be increasing, to work with the current
> process.  SHA1's are random.
Yes, but you can use "git describe" output:

$ git describe v1.7.6-180-gdf3f3d8

HTH, Santi

John Szakmeister· Jan 25, 2012, 02:18 UTC · re: Santi Béjar · lore

Re: Rebase and incrementing version numbers

On Thu, Jan 19, 2012 at 5:31 PM, Santi Béjar <santi@agolina.net> wrote: [snip]

> Yes, but you can use "git describe" output:
>
> $ git describe
> v1.7.6-180-gdf3f3d8

That doesn't work with git-svn. In Subversion, tags are closer to branches, which is how git-svn treats them.

-John
Carlos Martín Nieto· Jan 19, 2012, 19:20 UTC · re: Michael Nahas · lore

Re: Rebase and incrementing version numbers

On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:
Show 6 quoted lines
> 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?

Show 6 quoted lines
> 
> 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.

Show 5 quoted lines
> 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.

Show 6 quoted lines
> 
> 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
Michael Nahas· Jan 19, 2012, 20:02 UTC · re: Carlos Martín Nieto · lore

Re: Rebase and incrementing version numbers

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@elego.de> wrote:
Show 48 quoted lines
> 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
Carlos Martín Nieto· Jan 20, 2012, 15:53 UTC · re: Michael Nahas · lore

Re: Rebase and incrementing version numbers

On Thu, 2012-01-19 at 15:02 -0500, Michael Nahas wrote:
Show 15 quoted lines
> 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.

So your team has developed a VCS to run on top of the VCS you're using. This is a bit disconcerting. What's the point of svn if you're tracking the versions manually? Rolling back changes is one of the things that svn is there to help you with. There is no need for an extra layer. Separating production-ready changes with experimental changes is what branches are for.

From the way you explain the development/deployment cycle, it doesn't sound like any of the changes you dcommit should increase the version number except for the last one. If you increase the version number three times in one dcommit but you introduced the bug in the first of those, now you have to manually go back and try each version, which seems contrary to what the point of the scheme is.

   cmn
Show 58 quoted lines
> 
> 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@elego.de> 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
>
Christian Couder· Jan 25, 2012, 10:32 UTC · re: Carlos Martín Nieto · lore

Re: Rebase and incrementing version numbers

On Thu, Jan 19, 2012 at 8:20 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> 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.
By "merge" driver you mean a new merge startegy?

Isn't it possible to write a script and use it with git mergetool to automatically detect and resolve the merge conflicts resulting from changes in these numbers?

Regards, Christian.

Carlos Martín Nieto· Jan 25, 2012, 10:53 UTC · re: Christian Couder · lore

Re: Rebase and incrementing version numbers

On Wed, 2012-01-25 at 11:32 +0100, Christian Couder wrote:
Show 6 quoted lines
> On Thu, Jan 19, 2012 at 8:20 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> > 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.
> 
> By "merge" driver you mean a new merge startegy?
No. By "merge driver" I mean a "merge driver".
> 
> Isn't it possible to write a script and use it with git mergetool to
> automatically detect and resolve the merge conflicts resulting from
> changes in these numbers?

No. A mergetool is what you call manually to help you resolve a merge conflict. What you're describing is a merge driver. If you grep for "driver" in the merge manpage, you'll see how to set it, and it'll tell you to look in the gitattributes manpage for more information. If you search the web for "git merge driver" you'll see lots of examples of how these are done.

   cmn
Christian Couder· Jan 25, 2012, 11:18 UTC · re: Carlos Martín Nieto · lore

Re: Rebase and incrementing version numbers

On Wed, Jan 25, 2012 at 11:53 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
Show 5 quoted lines
> On Wed, 2012-01-25 at 11:32 +0100, Christian Couder wrote:
>>
>> By "merge" driver you mean a new merge startegy?
>
> No. By "merge driver" I mean a "merge driver".
Oops yeah, sorry, I should have searched.

Thanks, Christian.

Jehan Bing· Jan 19, 2012, 21:07 UTC · re: Michael Nahas · lore

Re: Rebase and incrementing version numbers

On 2012-01-19 09:20, Michael Nahas wrote:
Show 21 quoted lines
> 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.
>
> 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.
>
> 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!
>
> 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.

Maybe you can do something with "git rerere" (http://progit.org/2010/03/08/rerere.html). It supposed to automatically resolve known conflicts.

I've never used myself, I just know it exists, so I don't know it's usable in your case. But possibly you would pre-fill the rerere cache (assuming that the format is simple enough) then just run rebase.

	Jehan
Jon Seymour· Jan 19, 2012, 21:33 UTC · re: Michael Nahas · lore

Re: Rebase and incrementing version numbers

On Fri, Jan 20, 2012 at 4:20 AM, Michael Nahas <mike.nahas@gmail.com> wrote:
Show 27 quoted lines
> 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.
>
> 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.
>
> 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!
>
> 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.
>
> Thanks,
>
> Mike

I wonder if you can defer your changes to the config files until after you have synced with the current SVN head, so that you typically only modify the latest configuration file. Then use git to work out what numbers you have to update (by working out which files you changed that the SVN upstream has not seen yet). Not perfect, because of race conditions, and may not work with your integration testing processes, but perhaps worth considering.

Something like:
1. pull latest SVN
2. work on file
3. test. skip back to 2 until done.
4. ready to push to upstream
5. pull latest SVN
6. calculate configuration changes required
7. apply configuration changes
8. push work + configuration changes upstream

So, there is a window between steps 5 and 8 where you might still have to deal with a conflict, but at least it should be much reduced.

I agree with other comments, though, a saner approach might be to generate the configuration as part of a build process rather than trying to maintain it in source control.

jon.
Jeff King· Jan 25, 2012, 02:09 UTC · re: Jon Seymour · lore

Re: Rebase and incrementing version numbers

On Fri, Jan 20, 2012 at 08:33:57AM +1100, Jon Seymour wrote:
Show 7 quoted lines
> I wonder if you can defer your changes to the config files until after
> you have synced with the current SVN head, so that you typically only
> modify the latest configuration file. Then use git to work out what
> numbers you have to update (by working out which files you changed
> that the SVN upstream has not seen yet). Not perfect, because of race
> conditions, and may not work with your integration testing processes,
> but perhaps worth considering.

That was my thought, too (assuming this workflow, which seems slightly insane, is outside your power to change).

In this list here:
Show 10 quoted lines
> Something like:
> 
> 1. pull latest SVN
> 2. work on file
> 3. test. skip back to 2 until done.
> 4. ready to push to upstream
> 5. pull latest SVN
> 6. calculate configuration changes required
> 7. apply configuration changes
> 8. push work + configuration changes upstream

Steps 5 and 8 are basically "git svn dcommit". I suspect you could use some combination of "git svn rebase" and "git filter-branch" to rewrite your commits with the right counters, and then dcommit the result (hopefully fast enough to avoid races).

-Peff

← back to recent threads