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@xxxxxxxx> 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:
signature.asc
Description: This is a digitally signed message part