On Thu, Sep 09, 2004 at 01:40:58PM +0100, Steve Folly wrote:
> For a release, somebody will be assigned the job of creating a working
> copy of the main trunk and updating files as required to create a
> stable build. Meanwhile commits are still happening in the main trunk,
> but the release coordinator is only updating certain files required for
> the build. (99.9% of the time it's all files being committed, but some
> changes wont be required). The advantage of doing it this way rather
> than creating a release branch is that we don't need to merge changes
> from main trunk to branch; just update as and when. At a stable point
> (usually 1 hour before delivery :), that working copy is tagged as the
> release.
It's unclear to me why repeatedly running 'cvs update' on specific files
(which is what it sounds like you're doing) is harder than 'svn merge -r
329:330' (assuming you want the changes associated with revision 330).
If the problem is that your developers are committing unrelated changes
in single commits, then you have a procedural problem, and you're losing
one of SVN significant advantages over CVS (atomic commits). Apply the
cluebat liberally.
> This is what I can't get my head around with subversion - how to pick
> and choose which commits go into a working copy? Consider three commits
> to the repository, A, B and C, performed over time in that order. How
> can I have a working copy with only commits A and C, but not B?
See the above merge example. If all development is occuring only on the
trunk, and you'll never need to merge branch->trunk, this kind of cherry
picking is easy. If you *are* going to have merge back, then you may
have to do more bookkeeping. Or just cherry-pick indiviudal fixes, and
write good log messages.
> Should we now be thinking about creating a branch for a release in
> subversion, then we can pick and choose which updates we want. The only
> disadvantage to this is (I think) that we have to manually (i.e. tell
> svn) to merge files from the main trunk to the release branch.
But you have to manually pickout which files from CVS to update now,
right? Subversion will be easier, because you can pickout a *change*,
and get all the necessary files fixed.
Or maybe I've completely misunderstood what you're doing with CVS. But
as someone who has long used the "branch for release stabilization"
concept, and then struggled to deal with merging fixes from the trunk
("have I got *all* the files involved?" "I'm not picking up development
stuff too, am I?"), I'm really think that subversion is going to make
life a lot easier.
Steve
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
-- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 9 16:59:30 2004