The "svn copy" command's help states that the copy "remembers history."
After some experimentation (I've been using Subversion for a few months
now) I think I have a misunderstanding of what this means. Basically, I
assumed that a branch or a tag of the trunk behaves exactly like a true
copy (even though internally it is a quick copy.) The log of a branch
shows all the revisions in the branch, and then additionally all the
revisions of the original source line of code where the branch was
copied from. I'm guessing this is what is meant by "including history"
in a copy.
However, despite the fact I can see all changes in the log back to
revision 1 (and even surf through the diffs with TortoiseSVN very
easily) it seems I cannot get svn to apply the history before the point
of copy. Ie, if I branch the trunk at revision 100, check out a working
copy of the branch, I am unable to update to any revision before 100 on
that branch from there on out. For example, performing 'svn update -r
50' on the branch's working copy. Instead, I get the (uninformative :( )
error message "Cannot replace a directory from within."
It seems to me the best behavior for this command would be to back patch
the branch to revision 100 using the changes made within the branch
itself (ignoring the trunk) and then further back patch through the
trunk to revision 50. This way, the branch truly behaves like a copy of
the trunk at that point in time, including history. This is safe because
any commit will be made to the latest revision of the branch. It appears
the information is actually all there, since I can see it in the log,
but there is no way to apply it. Am I missing something, ie, are there
ambiguous cases or something that prevent this feature from being
implemented? Is there a workaround? Essentially my app does "svn
updates" all the way back through our old code and performs builds to
generate SQL for migration, but now that we've made release branches, it
breaks since it can no longer apply simple update commands to get to the
old versions of the code before that release when working within the branch.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jul 5 08:51:13 2005