On Fri, Jan 20, 2012 at 4:20 AM, Michael Nahas <mike.nahas@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html