Quoth trlists@clayst.com <mailto:trlists@clayst.com>:
> (1) Merge changes from live into dev first so that dev picks
> up the bugfixes. Then merge from dev back to live to update the
> trunk with the new features. Will this work? How would I choose
> which revisions to merge for the second merge?
This is the typical approach, AFAIK. The process is explained in the
SVN book, but AFAIK you basically just need to remember which revision
was HEAD in 'live' when you branched (or last merged from it). Then you
can merge in any changes made since then. Typically you do this by
noting it in the comments for the branch.
> (2) Use svn diff to find the changes in the live branch that are not
> yet in dev and make them manually, then merge changes only one way,
> from dev to live.
That's pretty much the same as #1, except that you're doing the grunt
work yourself :)
> (3) Merge from dev to live then delete the dev WC and get a
> new one off the live branch as the base for future development.
This won't work if people other than yourself are committing things to
'live'. Or if you're committing things to 'live' from outside the dev
branch. Which sounds like the case if you're worried about stray bugfix
code in the first place.
> #3 seems like the cleanest approach but it is complicated by the fact
> that I have bunch of unversioned stuff in the dev deirectories that I
> wouldn't want to lose, so I can't just delete the WC and do another
> checkout. Is there any way to remove all the versioned files from a
> directory tree, leaving only what is unversioned?
svn switch would probably work. Either switching to the latest branch
or to an empty folder. But I don't think #3 is the way to go anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 7 07:20:34 2005