Re: Rebase and incrementing version numbers
- From
Carlos Martín Nieto <cmn@elego.de>
- Date
- Jan 19, 2012, 19:20 UTC
- Message-ID
- <1327000803.5947.59.camel@centaur.lab.cmartin.tk>
- In-Reply-To
- <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
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