{"thread":{"id":"29403","subject":"Rebase and incrementing version numbers","startedAt":"2012-01-19T17:20:08Z","lastAt":"2012-01-25T11:18:56Z","messageCount":16,"participants":["Michael Nahas","demerphq","Carlos Martín Nieto","PJ Weisberg","Jehan Bing","Jon Seymour","Santi Béjar","Jeff King","John Szakmeister","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182795","messageId":"CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com","threadId":"29403","inReplyTo":"CADo4Y9jGYJasDL9m7_50aOTrOyoezdyg=vcsZhQ87Qk-1XfTUQ@mail.gmail.com","subject":"Rebase and incrementing version numbers","fromName":"Michael Nahas","fromEmail":"mike.nahas@gmail.com","sentAt":"2012-01-19T17:20:08Z","receivedAt":"2012-01-19T17:20:08Z","isPatch":false,"sender":{"key":"mike.nahas@gmail.com","avatar":null},"body":"I'm at a new job and using Git-SVN at a place that is accustomed to SVN.\n\nThe problem I'm running into is that whenever I change a file in a\ndirectory, I have to bump up the version number in the configuration\nfile.  The larger version value in the config file causes my changes\nto be loaded over the old ones.\n\nMost of my commits are edits to a file like \"foo.js\" and an increment\nto the version number in \"config\".  Ideally, each of my features\nshould live in a single commit and I should be able to make a sequence\nof them, each time incrementing the version number in config.\n\nThe problem I'm running into starts with me editing version=100.  I\ncreate new commits where I set the version to 101, 102, 103, 104.\nWhen I go to push (\"git svn dcommit\"), my coworkers have incremented\nthe version to 103.  So, I rebase my changes, and get conflicts every\ntime because of the version number!\n\nIs there a good way to avoid these conflicts?  Is there a hook I can\nwrite?  Is there a change to this process that would work smoother\nwith Git and its distributed development?  It's okay if the version\nnumber skips numbers (e.g., jumps from 100 to 104), as long as it\nincreases.\n\nThanks,\n\nMike\n"},{"id":"182796","messageId":"CANgJU+WWq=+BP1ZDbGY3weB5Xey2TtbryDJvz5=eMLFzNet3xQ@mail.gmail.com","threadId":"29403","inReplyTo":"CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-01-19T18:12:21Z","receivedAt":"2012-01-19T18:12:21Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 19 January 2012 18:20, Michael Nahas wrote:\n> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.\n>\n> The problem I'm running into is that whenever I change a file in a\n> directory, I have to bump up the version number in the configuration\n> file.  The larger version value in the config file causes my changes\n> to be loaded over the old ones.\n>\n> Most of my commits are edits to a file like \"foo.js\" and an increment\n> to the version number in \"config\".  Ideally, each of my features\n> should live in a single commit and I should be able to make a sequence\n> of them, each time incrementing the version number in config.\n>\n> The problem I'm running into starts with me editing version=100.  I\n> create new commits where I set the version to 101, 102, 103, 104.\n> When I go to push (\"git svn dcommit\"), my coworkers have incremented\n> the version to 103.  So, I rebase my changes, and get conflicts every\n> time because of the version number!\n>\n> Is there a good way to avoid these conflicts?  Is there a hook I can\n> write?  Is there a change to this process that would work smoother\n> with Git and its distributed development?  It's okay if the version\n> number skips numbers (e.g., jumps from 100 to 104), as long as it\n> increases.\n\nStop using version numbers and start using the git sha1 of the code\nyou are using.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"182800","messageId":"CADo4Y9is9mBOJaU+YRTMedTz7FfDrMFoDiqiUvQpVxQpyariPQ@mail.gmail.com","threadId":"29403","inReplyTo":"CANgJU+WWq=+BP1ZDbGY3weB5Xey2TtbryDJvz5=eMLFzNet3xQ@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Michael Nahas","fromEmail":"mike.nahas@gmail.com","sentAt":"2012-01-19T18:48:38Z","receivedAt":"2012-01-19T18:48:38Z","isPatch":false,"sender":{"key":"mike.nahas@gmail.com","avatar":null},"body":"On Thu, Jan 19, 2012 at 1:12 PM, demerphq wrote:\n> Stop using version numbers and start using the git sha1 of the code\n> you are using.\n>\n> Yves\n\n1. Others in the group use SVN.\n2. The version number needs to be increasing, to work with the current\nprocess. SHA1's are random.\n3. The \"git sha1\" for the commit/snapshot cannot be put into the\nconfig file, which is part of the snapshot.\n\nMike\n"},{"id":"182801","messageId":"1327000803.5947.59.camel@centaur.lab.cmartin.tk","threadId":"29403","inReplyTo":"CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-01-19T19:20:03Z","receivedAt":"2012-01-19T19:20:03Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:\n> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.\n> \n> The problem I'm running into is that whenever I change a file in a\n> directory, I have to bump up the version number in the configuration\n> file. The larger version value in the config file causes my changes\n> to be loaded over the old ones.\n\nIs this a deployment script that does this? Why can't it look at whether\nfiles have changed? If a feature isn't ready for production, why is it\nin a branch that gets deployed?\n\n> \n> Most of my commits are edits to a file like \"foo.js\" and an increment\n> to the version number in \"config\". Ideally, each of my features\n> should live in a single commit and I should be able to make a sequence\n> of them, each time incrementing the version number in config.\n> \n\nSo if you've changed the file but don't increase the config file's\nversion, it means that the change isn't ready for production? If that's\nthe case, you've just implemented branches, poorly.\n\nContrary to what apparently many people think, subversion does support\nbranches. Get your team to use them.\n\n> The problem I'm running into starts with me editing version=100. I\n> create new commits where I set the version to 101, 102, 103, 104.\n> When I go to push (\"git svn dcommit\"), my coworkers have incremented\n> the version to 103. So, I rebase my changes, and get conflicts every\n> time because of the version number!\n\nThis sounds like a race condition that the svn users might be avoiding\nby committing everything immediately. Sounds like a buggy development\nprocess.\n\n> \n> Is there a good way to avoid these conflicts? Is there a hook I can\n> write? Is there a change to this process that would work smoother\n> with Git and its distributed development? It's okay if the version\n> number skips numbers (e.g., jumps from 100 to 104), as long as it\n> increases.\n\nYou could write a merge driver that detects this situation and writes in\na higher number, but it's all working around the fact that it's a race\ncondition.\n\n cmn\n"},{"id":"182805","messageId":"CAJsNXTkDdHTMqmXCynT2nEYyuTmSF53RVtG2V+v7b+qcsYYufg@mail.gmail.com","threadId":"29403","inReplyTo":"CADo4Y9is9mBOJaU+YRTMedTz7FfDrMFoDiqiUvQpVxQpyariPQ@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-01-19T19:58:28Z","receivedAt":"2012-01-19T19:58:28Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Thu, Jan 19, 2012 at 10:48 AM, Michael Nahas wrote:\n> On Thu, Jan 19, 2012 at 1:12 PM, demerphq wrote:\n>> Stop using version numbers and start using the git sha1 of the code\n>> you are using.\n>>\n>> Yves\n>\n> 1. Others in the group use SVN.\n> 2. The version number needs to be increasing, to work with the current\n> process.  SHA1's are random.\n> 3. The \"git sha1\" for the commit/snapshot cannot be put into the\n> config file, which is part of the snapshot.\n\nSuggestion #1: Just put $Rev$ into the file and be done with it until\nthe team moves over to Git (at which point you can figure something\nelse out).\n\nSuggestion #2: In your release process, put something like `sed -e\n\"s/@@id@@/$(date +%s)/\" source-dir/config > release-dir/config`\n\n-PJ\n"},{"id":"182804","messageId":"CADo4Y9iJyirdkEr1GCg9BD5rwX9=1uKptqHsiWB0_MiDKb_wUA@mail.gmail.com","threadId":"29403","inReplyTo":"1327000803.5947.59.camel@centaur.lab.cmartin.tk","subject":"Re: Rebase and incrementing version numbers","fromName":"Michael Nahas","fromEmail":"mike.nahas@gmail.com","sentAt":"2012-01-19T20:02:46Z","receivedAt":"2012-01-19T20:02:46Z","isPatch":false,"sender":{"key":"mike.nahas@gmail.com","avatar":null},"body":"I'm guessing here, but I believe the \"version number\" is used to make\na directory on the production machine. Thus, older versions of the\njavascript are available on the production machines under their older\nversion number. If there's an issue in production with the new\nversion, code can be redirected to use the older version that is still\nin its directory.\n\nSo it probably looks like:\n/100/js/\n/101/js/\n/103/js/\n/104/js/\n\nIf something goes wrong with version 104, the admin can just tell the\nmachine to use version 103 instead of 104.\n\nYou're right that incrementing this version number is probably not an\nissue for SVN users because they put N features in a single commit and\nthey update the version number once. With git, a user can put N\nfeatures in N commits and changing the version number really belongs\nin each commit. This makes rebasing suck.\n\n\nOn Thu, Jan 19, 2012 at 2:20 PM, Carlos Martín Nieto wrote:\n> On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:\n>> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.\n>>\n>> The problem I'm running into is that whenever I change a file in a\n>> directory, I have to bump up the version number in the configuration\n>> file.  The larger version value in the config file causes my changes\n>> to be loaded over the old ones.\n>\n> Is this a deployment script that does this? Why can't it look at whether\n> files have changed? If a feature isn't ready for production, why is it\n> in a branch that gets deployed?\n>\n>>\n>> Most of my commits are edits to a file like \"foo.js\" and an increment\n>> to the version number in \"config\".  Ideally, each of my features\n>> should live in a single commit and I should be able to make a sequence\n>> of them, each time incrementing the version number in config.\n>>\n>\n> So if you've changed the file but don't increase the config file's\n> version, it means that the change isn't ready for production? If that's\n> the case, you've just implemented branches, poorly.\n>\n> Contrary to what apparently many people think, subversion does support\n> branches. Get your team to use them.\n>\n>> The problem I'm running into starts with me editing version=100.  I\n>> create new commits where I set the version to 101, 102, 103, 104.\n>> When I go to push (\"git svn dcommit\"), my coworkers have incremented\n>> the version to 103.  So, I rebase my changes, and get conflicts every\n>> time because of the version number!\n>\n> This sounds like a race condition that the svn users might be avoiding\n> by committing everything immediately. Sounds like a buggy development\n> process.\n>\n>>\n>> Is there a good way to avoid these conflicts?  Is there a hook I can\n>> write?  Is there a change to this process that would work smoother\n>> with Git and its distributed development?  It's okay if the version\n>> number skips numbers (e.g., jumps from 100 to 104), as long as it\n>> increases.\n>\n> You could write a merge driver that detects this situation and writes in\n> a higher number, but it's all working around the fact that it's a race\n> condition.\n>\n>   cmn\n"},{"id":"182806","messageId":"CADo4Y9hFgd5vU-EY6x4=hUyVDmANmgw6mH0u2=7Me=yFO5n2kg@mail.gmail.com","threadId":"29403","inReplyTo":"CAJsNXTkDdHTMqmXCynT2nEYyuTmSF53RVtG2V+v7b+qcsYYufg@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Michael Nahas","fromEmail":"mike.nahas@gmail.com","sentAt":"2012-01-19T20:06:10Z","receivedAt":"2012-01-19T20:06:10Z","isPatch":false,"sender":{"key":"mike.nahas@gmail.com","avatar":null},"body":"> Suggestion #1:  Just put $Rev$ into the file and be done with it until\n> the team moves over to Git (at which point you can figure something\n> else out).\n>\n> Suggestion #2:  In your release process, put something like `sed -e\n> \"s/@@id@@/$(date +%s)/\" source-dir/config > release-dir/config`\n>\n> -PJ\n\nIdeally, this value only increments with a change in a certain directory.\n\nI think using either $Rev$ or a data+time value conditioned on a file\nchanging in a directory might work. Thanks!\n\nMike\n"},{"id":"182811","messageId":"4F188611.20205@orb.com","threadId":"29403","inReplyTo":"CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Jehan Bing","fromEmail":"jehan@orb.com","sentAt":"2012-01-19T21:07:29Z","receivedAt":"2012-01-19T21:07:29Z","isPatch":false,"sender":{"key":"jehan@orb.com","avatar":null},"body":"On 2012-01-19 09:20, Michael Nahas wrote:\n> The problem I'm running into is that whenever I change a file in a\n> directory, I have to bump up the version number in the configuration\n> file. The larger version value in the config file causes my changes\n> to be loaded over the old ones.\n>\n> Most of my commits are edits to a file like \"foo.js\" and an increment\n> to the version number in \"config\". Ideally, each of my features\n> should live in a single commit and I should be able to make a sequence\n> of them, each time incrementing the version number in config.\n>\n> The problem I'm running into starts with me editing version=100. I\n> create new commits where I set the version to 101, 102, 103, 104.\n> When I go to push (\"git svn dcommit\"), my coworkers have incremented\n> the version to 103. So, I rebase my changes, and get conflicts every\n> time because of the version number!\n>\n> Is there a good way to avoid these conflicts? Is there a hook I can\n> write? Is there a change to this process that would work smoother\n> with Git and its distributed development? It's okay if the version\n> number skips numbers (e.g., jumps from 100 to 104), as long as it\n> increases.\n\nMaybe you can do something with \"git rerere\" \n(http://progit.org/2010/03/08/rerere.html). It supposed to automatically \nresolve known conflicts.\n\nI've never used myself, I just know it exists, so I don't know it's \nusable in your case. But possibly you would pre-fill the rerere cache \n(assuming that the format is simple enough) then just run rebase.\n\n\tJehan\n"},{"id":"182814","messageId":"CAH3Anro8T4SJqBvw1E_7u__4kYyB6hMCYPbtHSVxkgSUYSb2+A@mail.gmail.com","threadId":"29403","inReplyTo":"CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-01-19T21:33:57Z","receivedAt":"2012-01-19T21:33:57Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Fri, Jan 20, 2012 at 4:20 AM, Michael Nahas wrote:\n> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.\n>\n> The problem I'm running into is that whenever I change a file in a\n> directory, I have to bump up the version number in the configuration\n> file.  The larger version value in the config file causes my changes\n> to be loaded over the old ones.\n>\n> Most of my commits are edits to a file like \"foo.js\" and an increment\n> to the version number in \"config\".  Ideally, each of my features\n> should live in a single commit and I should be able to make a sequence\n> of them, each time incrementing the version number in config.\n>\n> The problem I'm running into starts with me editing version=100.  I\n> create new commits where I set the version to 101, 102, 103, 104.\n> When I go to push (\"git svn dcommit\"), my coworkers have incremented\n> the version to 103.  So, I rebase my changes, and get conflicts every\n> time because of the version number!\n>\n> Is there a good way to avoid these conflicts?  Is there a hook I can\n> write?  Is there a change to this process that would work smoother\n> with Git and its distributed development?  It's okay if the version\n> number skips numbers (e.g., jumps from 100 to 104), as long as it\n> increases.\n>\n> Thanks,\n>\n> Mike\n\nI wonder if you can defer your changes to the config files until after\nyou have synced with the current SVN head, so that you typically only\nmodify the latest configuration file. Then use git to work out what\nnumbers you have to update (by working out which files you changed\nthat the SVN upstream has not seen yet). Not perfect, because of race\nconditions, and may not work with your integration testing processes,\nbut perhaps worth considering.\n\nSomething like:\n\n1. pull latest SVN\n2. work on file\n3. test. skip back to 2 until done.\n4. ready to push to upstream\n5. pull latest SVN\n6. calculate configuration changes required\n7. apply configuration changes\n8. push work + configuration changes upstream\n\nSo, there is a window between steps 5 and 8 where you might still have\nto deal with a conflict, but at least it should be much reduced.\n\nI agree with other comments, though, a saner approach might be to\ngenerate the configuration as part of a build process rather than\ntrying to maintain it in source control.\n\njon.\n"},{"id":"182821","messageId":"CA+gHt1CPBYTLLwSSLdu-BmDfuGDzPwi9RnXAku7KZjHLYhUtjQ@mail.gmail.com","threadId":"29403","inReplyTo":"CADo4Y9is9mBOJaU+YRTMedTz7FfDrMFoDiqiUvQpVxQpyariPQ@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2012-01-19T23:31:19Z","receivedAt":"2012-01-19T23:31:19Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Thu, Jan 19, 2012 at 7:48 PM, Michael Nahas wrote:\n> On Thu, Jan 19, 2012 at 1:12 PM, demerphq wrote:\n>> Stop using version numbers and start using the git sha1 of the code\n>> you are using.\n>>\n>> Yves\n>\n[...]\n> 2. The version number needs to be increasing, to work with the current\n> process.  SHA1's are random.\n\nYes, but you can use \"git describe\" output:\n\n$ git describe\nv1.7.6-180-gdf3f3d8\n\nHTH,\nSanti\n"},{"id":"182858","messageId":"1327074827.31804.21.camel@centaur.lab.cmartin.tk","threadId":"29403","inReplyTo":"CADo4Y9iJyirdkEr1GCg9BD5rwX9=1uKptqHsiWB0_MiDKb_wUA@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-01-20T15:53:47Z","receivedAt":"2012-01-20T15:53:47Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2012-01-19 at 15:02 -0500, Michael Nahas wrote:\n> I'm guessing here, but I believe the \"version number\" is used to make\n> a directory on the production machine. Thus, older versions of the\n> javascript are available on the production machines under their older\n> version number. If there's an issue in production with the new\n> version, code can be redirected to use the older version that is still\n> in its directory.\n> \n> So it probably looks like:\n> /100/js/\n> /101/js/\n> /103/js/\n> /104/js/\n> \n> If something goes wrong with version 104, the admin can just tell the\n> machine to use version 103 instead of 104.\n\nSo your team has developed a VCS to run on top of the VCS you're using.\nThis is a bit disconcerting. What's the point of svn if you're tracking\nthe versions manually? Rolling back changes is one of the things that\nsvn is there to help you with. There is no need for an extra layer.\nSeparating production-ready changes with experimental changes is what\nbranches are for.\n\nFrom the way you explain the development/deployment cycle, it doesn't\nsound like any of the changes you dcommit should increase the version\nnumber except for the last one. If you increase the version number three\ntimes in one dcommit but you introduced the bug in the first of those,\nnow you have to manually go back and try each version, which seems\ncontrary to what the point of the scheme is.\n\n cmn\n\n> \n> You're right that incrementing this version number is probably not an\n> issue for SVN users because they put N features in a single commit and\n> they update the version number once. With git, a user can put N\n> features in N commits and changing the version number really belongs\n> in each commit. This makes rebasing suck.\n> \n> \n> On Thu, Jan 19, 2012 at 2:20 PM, Carlos Martín Nieto wrote:\n> > On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:\n> >> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.\n> >>\n> >> The problem I'm running into is that whenever I change a file in a\n> >> directory, I have to bump up the version number in the configuration\n> >> file. The larger version value in the config file causes my changes\n> >> to be loaded over the old ones.\n> >\n> > Is this a deployment script that does this? Why can't it look at whether\n> > files have changed? If a feature isn't ready for production, why is it\n> > in a branch that gets deployed?\n> >\n> >>\n> >> Most of my commits are edits to a file like \"foo.js\" and an increment\n> >> to the version number in \"config\". Ideally, each of my features\n> >> should live in a single commit and I should be able to make a sequence\n> >> of them, each time incrementing the version number in config.\n> >>\n> >\n> > So if you've changed the file but don't increase the config file's\n> > version, it means that the change isn't ready for production? If that's\n> > the case, you've just implemented branches, poorly.\n> >\n> > Contrary to what apparently many people think, subversion does support\n> > branches. Get your team to use them.\n> >\n> >> The problem I'm running into starts with me editing version=100. I\n> >> create new commits where I set the version to 101, 102, 103, 104.\n> >> When I go to push (\"git svn dcommit\"), my coworkers have incremented\n> >> the version to 103. So, I rebase my changes, and get conflicts every\n> >> time because of the version number!\n> >\n> > This sounds like a race condition that the svn users might be avoiding\n> > by committing everything immediately. Sounds like a buggy development\n> > process.\n> >\n> >>\n> >> Is there a good way to avoid these conflicts? Is there a hook I can\n> >> write? Is there a change to this process that would work smoother\n> >> with Git and its distributed development? It's okay if the version\n> >> number skips numbers (e.g., jumps from 100 to 104), as long as it\n> >> increases.\n> >\n> > You could write a merge driver that detects this situation and writes in\n> > a higher number, but it's all working around the fact that it's a race\n> > condition.\n> >\n> > cmn\n> \n\n\n"},{"id":"183062","messageId":"20120125020903.GA21535@sigill.intra.peff.net","threadId":"29403","inReplyTo":"CAH3Anro8T4SJqBvw1E_7u__4kYyB6hMCYPbtHSVxkgSUYSb2+A@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-25T02:09:03Z","receivedAt":"2012-01-25T02:09:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 20, 2012 at 08:33:57AM +1100, Jon Seymour wrote:\n\n> I wonder if you can defer your changes to the config files until after\n> you have synced with the current SVN head, so that you typically only\n> modify the latest configuration file. Then use git to work out what\n> numbers you have to update (by working out which files you changed\n> that the SVN upstream has not seen yet). Not perfect, because of race\n> conditions, and may not work with your integration testing processes,\n> but perhaps worth considering.\n\nThat was my thought, too (assuming this workflow, which seems slightly\ninsane, is outside your power to change).\n\nIn this list here:\n\n> Something like:\n> \n> 1. pull latest SVN\n> 2. work on file\n> 3. test. skip back to 2 until done.\n> 4. ready to push to upstream\n> 5. pull latest SVN\n> 6. calculate configuration changes required\n> 7. apply configuration changes\n> 8. push work + configuration changes upstream\n\nSteps 5 and 8 are basically \"git svn dcommit\". I suspect you could use\nsome combination of \"git svn rebase\" and \"git filter-branch\" to rewrite\nyour commits with the right counters, and then dcommit the result\n(hopefully fast enough to avoid races).\n\n-Peff\n"},{"id":"183063","messageId":"CAEBDL5XF3uiCSih4U9jJwmHMAaUqGh+9mXRFxyHNTqEn61K8PQ@mail.gmail.com","threadId":"29403","inReplyTo":"CA+gHt1CPBYTLLwSSLdu-BmDfuGDzPwi9RnXAku7KZjHLYhUtjQ@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2012-01-25T02:18:49Z","receivedAt":"2012-01-25T02:18:49Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Thu, Jan 19, 2012 at 5:31 PM, Santi Béjar wrote:\n[snip]\n> Yes, but you can use \"git describe\" output:\n>\n> $ git describe\n> v1.7.6-180-gdf3f3d8\n\nThat doesn't work with git-svn. In Subversion, tags are closer to\nbranches, which is how git-svn treats them.\n\n-John\n"},{"id":"183075","messageId":"CAP8UFD0gd_-=Cc0vox-6Ts4-iBWcJG8LgmqXteXgp3qc-bX13w@mail.gmail.com","threadId":"29403","inReplyTo":"1327000803.5947.59.camel@centaur.lab.cmartin.tk","subject":"Re: Rebase and incrementing version numbers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2012-01-25T10:32:08Z","receivedAt":"2012-01-25T10:32:08Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jan 19, 2012 at 8:20 PM, Carlos Martín Nieto wrote:\n> You could write a merge driver that detects this situation and writes in\n> a higher number, but it's all working around the fact that it's a race\n> condition.\n\nBy \"merge\" driver you mean a new merge startegy?\n\nIsn't it possible to write a script and use it with git mergetool to\nautomatically detect and resolve the merge conflicts resulting from\nchanges in these numbers?\n\nRegards,\nChristian.\n"},{"id":"183076","messageId":"1327488820.3052.15.camel@beez.lab.cmartin.tk","threadId":"29403","inReplyTo":"CAP8UFD0gd_-=Cc0vox-6Ts4-iBWcJG8LgmqXteXgp3qc-bX13w@mail.gmail.com","subject":"Re: Rebase and incrementing version numbers","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-01-25T10:53:40Z","receivedAt":"2012-01-25T10:53:40Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, 2012-01-25 at 11:32 +0100, Christian Couder wrote:\n> On Thu, Jan 19, 2012 at 8:20 PM, Carlos Martín Nieto wrote:\n> > You could write a merge driver that detects this situation and writes in\n> > a higher number, but it's all working around the fact that it's a race\n> > condition.\n> \n> By \"merge\" driver you mean a new merge startegy?\n\nNo. By \"merge driver\" I mean a \"merge driver\".\n\n> \n> Isn't it possible to write a script and use it with git mergetool to\n> automatically detect and resolve the merge conflicts resulting from\n> changes in these numbers?\n\nNo. A mergetool is what you call manually to help you resolve a merge\nconflict. What you're describing is a merge driver. If you grep for\n\"driver\" in the merge manpage, you'll see how to set it, and it'll tell\nyou to look in the gitattributes manpage for more information. If you\nsearch the web for \"git merge driver\" you'll see lots of examples of how\nthese are done.\n\n cmn\n\n\n"},{"id":"183077","messageId":"CAP8UFD080jii=86+EXkLC_Dmcs52j+ta=-i=6b1KedC=8WQ6MQ@mail.gmail.com","threadId":"29403","inReplyTo":"1327488820.3052.15.camel@beez.lab.cmartin.tk","subject":"Re: Rebase and incrementing version numbers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2012-01-25T11:18:56Z","receivedAt":"2012-01-25T11:18:56Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Jan 25, 2012 at 11:53 AM, Carlos Martín Nieto wrote:\n> On Wed, 2012-01-25 at 11:32 +0100, Christian Couder wrote:\n>>\n>> By \"merge\" driver you mean a new merge startegy?\n>\n> No. By \"merge driver\" I mean a \"merge driver\".\n\nOops yeah, sorry, I should have searched.\n\nThanks,\nChristian.\n"}]}