Rebase and incrementing version numbers

Rebase and incrementing version numbers

[Michael Nahas]

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

Re: Rebase and incrementing version numbers

[demerphq]

On 19 January 2012 18:20, Michael Nahas <mike.nahas@gmail.com> 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/"

Re: Rebase and incrementing version numbers

[Michael Nahas]

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

Re: Rebase and incrementing version numbers

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Rebase and incrementing version numbers

[PJ Weisberg]

On Thu, Jan 19, 2012 at 10:48 AM, Michael Nahas <mike.nahas@gmail.com> wrote:
> 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

Re: Rebase and incrementing version numbers

[Michael Nahas]

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:
> 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

Re: Rebase and incrementing version numbers

[Michael Nahas]

> 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

Re: Rebase and incrementing version numbers

[Jehan Bing]

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

Re: Rebase and incrementing version numbers

[Jon Seymour]

On Fri, Jan 20, 2012 at 4:20 AM, Michael Nahas <mike.nahas@gmail.com> 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.

Re: Rebase and incrementing version numbers

[Santi Béjar]

On Thu, Jan 19, 2012 at 7:48 PM, Michael Nahas <mike.nahas@gmail.com> wrote:
> 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

Re: Rebase and incrementing version numbers

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 4169 bytes --]

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/<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

> 
> 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
> 



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Rebase and incrementing version numbers

[Jeff King]

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

Re: Rebase and incrementing version numbers

[John Szakmeister]

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

Re: Rebase and incrementing version numbers

[Christian Couder]

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.

Re: Rebase and incrementing version numbers

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

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 <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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Rebase and incrementing version numbers

[Christian Couder]

On Wed, Jan 25, 2012 at 11:53 AM, Carlos Martín Nieto <cmn@elego.de> 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.