I understand the preferred method of branching, but why does tsvn allow
you to branch directly from your wc in one step if this is not
supported? Logically it should be the same; causing a copy to be made
from the BASE rev in your wc instead of the HEAD rev in the repository,
then committing your changes. In fact, this appears to be what the logs
of the branch show happened, yet there is a hole in the revision history
where svn can not find that the files existed, but were unchanged since
the previous version. The history shows the file was copied from
version x and modified in version x+y, so why doesn't svn infer that the
file existed but was unchanged in the intervening versions?
The problem only happens if there are versions between the BASE of the
wc at the time of the copy and HEAD. If the wc is at HEAD when you copy
it to a branch, everything works fine. Svn can find the history flowing
back from the commit that created the branch. However if someone else
has made commits between your last wc update and the copy to the branch,
those versions in between get clobbered in the history of the branch.
It does not seem it should be possible for a file to exist at point x,
and at point y, but not to exist in between, when it was neither created
nor destroyed in that time.
Another way to duplicate this problem is to copy a branch from a version
other than HEAD. For instance, if HEAD is at 7, and you svn copy -r 4
/repo/trunk /repo/branch, then the revisions 5, 6, and 7 can not be
found in /repo/branch, but 4 can be.
Mark Phippard wrote:
>> You should not create a branch and commit changes to it in one
>> revision. You should split these logically distinct tasks into two
>> First, copy the trunk to a new branch. That should be the only step
>> performed in this revision.
>> Then, check out a working copy of the branch (or switch an existing
>> working copy of the trunk or any other branch (with changes if you
>> like)) to the new branch. Then make and/or finish up your changes and
>> commit again.
>> Now, when you merge these back to trunk, you start from the revision
>> in which the branch was created.
> Ryan's answer covers this well, but if you want to read a more verbose
> version of the same answer, I had a blog post about it a while ago:
> Sometimes it helps to read the same thing written multiple ways.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Feb 12 17:41:17 2007