# Rebase and incrementing version numbers 16 messages from 2012-01-19 to 2012-01-25. Participants: Michael Nahas, demerphq, Carlos Martín Nieto, PJ Weisberg, Jehan Bing, Jon Seymour, Santi Béjar, Jeff King, John Szakmeister, Christian Couder. Thread: https://gitlist.dev/t/29403 ## Michael Nahas, 2012-01-19 17:20 Subject: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CADo4Y9iKvoXhKg5pEAB%2BcbA7Rkfa%3DnF4TLu0xgcS3dnkNi_n4g%40mail.gmail.com In-Reply-To: ``` 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, 2012-01-19 18:12 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CANgJU%2BWWq%3D%2BBP1ZDbGY3weB5Xey2TtbryDJvz5%3DeMLFzNet3xQ%40mail.gmail.com In-Reply-To: ``` On 19 January 2012 18:20, 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. > > 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, 2012-01-19 18:48 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CADo4Y9is9mBOJaU%2BYRTMedTz7FfDrMFoDiqiUvQpVxQpyariPQ%40mail.gmail.com In-Reply-To: ``` On Thu, Jan 19, 2012 at 1:12 PM, demerphq 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 ``` ## Carlos Martín Nieto, 2012-01-19 19:20 Subject: Re: Rebase and incrementing version numbers Message-ID: <1327000803.5947.59.camel@centaur.lab.cmartin.tk> URL: https://gitlist.dev/e/1327000803.5947.59.camel%40centaur.lab.cmartin.tk In-Reply-To: ``` 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 ``` ## PJ Weisberg, 2012-01-19 19:58 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CAJsNXTkDdHTMqmXCynT2nEYyuTmSF53RVtG2V%2Bv7b%2BqcsYYufg%40mail.gmail.com In-Reply-To: ``` On Thu, Jan 19, 2012 at 10:48 AM, Michael Nahas wrote: > On Thu, Jan 19, 2012 at 1:12 PM, demerphq 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, 2012-01-19 20:02 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CADo4Y9iJyirdkEr1GCg9BD5rwX9%3D1uKptqHsiWB0_MiDKb_wUA%40mail.gmail.com In-Reply-To: <1327000803.5947.59.camel@centaur.lab.cmartin.tk> ``` 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/ /101/js/ /103/js/ /104/js/ 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 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 ``` ## Michael Nahas, 2012-01-19 20:06 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CADo4Y9hFgd5vU-EY6x4%3DhUyVDmANmgw6mH0u2%3D7Me%3DyFO5n2kg%40mail.gmail.com In-Reply-To: ``` > 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 ``` ## Jehan Bing, 2012-01-19 21:07 Subject: Re: Rebase and incrementing version numbers Message-ID: <4F188611.20205@orb.com> URL: https://gitlist.dev/e/4F188611.20205%40orb.com In-Reply-To: ``` On 2012-01-19 09:20, Michael Nahas wrote: > 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, 2012-01-19 21:33 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CAH3Anro8T4SJqBvw1E_7u__4kYyB6hMCYPbtHSVxkgSUYSb2%2BA%40mail.gmail.com In-Reply-To: ``` On Fri, Jan 20, 2012 at 4:20 AM, 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. > > 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. ``` ## Santi Béjar, 2012-01-19 23:31 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CA%2BgHt1CPBYTLLwSSLdu-BmDfuGDzPwi9RnXAku7KZjHLYhUtjQ%40mail.gmail.com In-Reply-To: ``` On Thu, Jan 19, 2012 at 7:48 PM, Michael Nahas wrote: > On Thu, Jan 19, 2012 at 1:12 PM, demerphq 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 ``` ## Carlos Martín Nieto, 2012-01-20 15:53 Subject: Re: Rebase and incrementing version numbers Message-ID: <1327074827.31804.21.camel@centaur.lab.cmartin.tk> URL: https://gitlist.dev/e/1327074827.31804.21.camel%40centaur.lab.cmartin.tk In-Reply-To: ``` On Thu, 2012-01-19 at 15:02 -0500, Michael Nahas wrote: > 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/ > /101/js/ > /103/js/ > /104/js/ > > 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 > > 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 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 > ``` ## Jeff King, 2012-01-25 02:09 Subject: Re: Rebase and incrementing version numbers Message-ID: <20120125020903.GA21535@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120125020903.GA21535%40sigill.intra.peff.net In-Reply-To: ``` On Fri, Jan 20, 2012 at 08:33:57AM +1100, Jon Seymour wrote: > 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: > 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 ``` ## John Szakmeister, 2012-01-25 02:18 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CAEBDL5XF3uiCSih4U9jJwmHMAaUqGh%2B9mXRFxyHNTqEn61K8PQ%40mail.gmail.com In-Reply-To: ``` On Thu, Jan 19, 2012 at 5:31 PM, Santi Béjar 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 ``` ## Christian Couder, 2012-01-25 10:32 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CAP8UFD0gd_-%3DCc0vox-6Ts4-iBWcJG8LgmqXteXgp3qc-bX13w%40mail.gmail.com In-Reply-To: <1327000803.5947.59.camel@centaur.lab.cmartin.tk> ``` On Thu, Jan 19, 2012 at 8:20 PM, Carlos Martín Nieto 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, 2012-01-25 10:53 Subject: Re: Rebase and incrementing version numbers Message-ID: <1327488820.3052.15.camel@beez.lab.cmartin.tk> URL: https://gitlist.dev/e/1327488820.3052.15.camel%40beez.lab.cmartin.tk In-Reply-To: ``` On Wed, 2012-01-25 at 11:32 +0100, Christian Couder wrote: > On Thu, Jan 19, 2012 at 8:20 PM, Carlos Martín Nieto 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, 2012-01-25 11:18 Subject: Re: Rebase and incrementing version numbers Message-ID: URL: https://gitlist.dev/e/CAP8UFD080jii%3D86%2BEXkLC_Dmcs52j%2Bta%3D-i%3D6b1KedC%3D8WQ6MQ%40mail.gmail.com In-Reply-To: <1327488820.3052.15.camel@beez.lab.cmartin.tk> ``` On Wed, Jan 25, 2012 at 11:53 AM, Carlos Martín Nieto wrote: > 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. ```