Kenneth Porter wrote:
> --On Saturday, September 25, 2004 10:42 PM -0700 Ray Johnson
> <Rayj@ingenio.com> wrote:
>
>> It is the notion that I could work on my working copy for a while & then
>> "put it away" into the revision control system - with out actually
>> checking it into the trunk.
>
> It sounds like branching, but a sort of "after the fact" branching where
> you've already made the edits and need to check them into a new branch
> instead of the branch you originally started from. (It need not be the
> trunk.)
>
> I'd guess (haven't tried this) that you'd need to branch the node you
> started from (ie. "svn cp"), then switch your WC to that branch, and then
> commit.
You're still thinking like CVS :-) In svn, tagging and branching are both
copies, and urls and wc paths are fairly (though not entirely)
interchangeable. You don't need to mess around to put your working dir out
on a branch somewhere (in fact, this part works so nicely I might consider
adding /sandbox to /trunk,/branches, and /tags in my repositories...
so, all you'd have to do to save your working state into the repository is:
svn add any-new-files # for new files, tell svn to track them
svn cp . $repo/sandbox/working-on-foobar # save the sandbox
svn revert -R . # get back to trunk
# NOTE: the svn adds are gone, but this won't remove new files from the WC
unfortunately, it isn't nearly as nice when you go to pick it back up.
Obviously there's a merge operation here, so it won't be totally seamless
(it can't be, there might be conflicts), but it does seem that this is
harder than it needs to be.
svn switch $repo/sandbox/working-on-foobar
# you get the 6 from the branch point logs message, as described in
# http://svnbook.red-bean.com/svnbook-1.0/ch04s04.html#svn-ch-4-sect-4.1
svn merge svn merge -r 6:HEAD $repo/trunk
svn cp . $repo/trunk
svn switch $repo/trunk
# go back to working, commit eventually...
----- and here, I switch from explaining things, to being confused myself
and seeking help from even greater gurus... -----
any thoughts from smarter subversioners on how this part could be more
painless? what you really want to do is merge the changes from the
ancestral trunk versions to the preserved sandbox data back onto the trunk,
but as the sandbox name didn't exist then, it's really rather painful to
do.
I see one other possible approach, which is less clunky but not entirely
correct. You could, as long as the WC you copied from wasn't mixed-version,
do it with:
svn merge -r 5:HEAD $repo/sandbox/working-on-foobar
with subversion 1.1, or
svn merge $repo/trunk@5 $repo/sandbox/working-on-foobar
in 1.0.x
1.0.x Note: the first form fails with the rather cryptic "Cannot replace a
directory from within", but I suspect the real problem is the one shown by:
svn diff -r5:HEAD file:///tmp/test/tags/working
which is
svn: 'file:///tmp/test/tags/working' was not found in the repository at
revision 5
But, since both of these commands (the diff and the merge) seem to follow
the copy correctly in 1.1, I'll assume that part is already fixed
However, this approach has a major drawback: it requires knowing that the
working directory when the branch was made was at revision 5, rather than
knowing that the branch was created in revision 6. While just using n-1
works pretty well in most cases, if you had a mixed-revision working copy
at the point when you saved your sandbox, or if the WC wasn't up-to-date at
the point it was saved (which seems at least plausible) it's not going to
to be work to do it this way.
----- and now I just get grumpy - so I'll let you know in advance how much I
appreciate SVN , even if this particular facet seems flawed -----
What bugs me is that SVN clearly knows the ancestor versions for each file
(and svn log -v will show them to you) but I can't for the life of me
figure out how to tell svn that I want to merge all changes off a branch,
from creation to HEAD, unless either a) the branch started form a
consistent, checked-in point that I can specify with a revnum or b) I want
to do it one file at a time. In both cases, it's only possible by manually
looking up logs and doing the merge from those revisions.
I know that merge tracking is still out on the radar, but not even having
some way of stating 'since this branch was created' is a more serious
problem than the continued merges one, since even documenting when and what
was merged isn't enough to overcome it. The only reliable way I see is to
perform the merge in the other direction first, and even that only works if
you assume that nobody is doing copies targetting trunk (which, in all
fairness, does seem like a decent assumption). When you have a copy
starting from a wc, you just can't capture the ancestry of the branch with
a single revnum in all cases, and that's all you can use to specify a
merge.
To be specific, if not complete, a revnum is insufficient if two conditions
both occur:
1) the branches ancestry is from from multiple source paths, a mixed-rev
WC, or an out-of-date WC (all which break the n-1 rule for picking a base
revision)
2) The very first revision of the branch contains changes, instead of being
an exact copy if its ancestor (ie, it was copied from a modified wc instead
of from a URL@revnum). Otherwise, you could merge from n, the revision in
which the branch was created - but then you'd miss these very first changes
(the example of merging an entire branch in The Book has this very
problem...)
Trying to use this feature to shelve a WC is likely to cause both of these
cases to occur (think out-of-date and modified...), which means the merge
just doesn't really work. The case of merging a branches entire life needs
some special help... after that, at least a revnum is sufficient to
quantify the points where changes were made (so continued merges are merely
a bit awkward).
Ok, now I assume I've missed something, so someone please smack me up and
show me how to merge an entire branch reliably, and I'll write it up for
The Book as an act of contrition for this abominably long email... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 27 03:21:55 2004