On Wed, 2004-06-30 at 16:52, Chris Withers wrote:
> Now, the problem turned out to be, with much help from Ben Reser, to be that
> vendor/Product/1.1 and cendor/Product/1.2 had no common ancestry. Once I'd
> really "done it by the [red bean] book", it worked as it should.
> I know what I was doing would have resulted in the repository taking up more
> space on disk, but surely it should have worked?
>From the book,
"Most merges involve comparing trees that are ancestrally related to one
another, and therefore svn merge defaults to this behavior.
Occasionally, however, you may want the merge command to compare two
unrelated trees. For example, you may have imported two source-code
trees representing different vendor releases of a software project (see
Section , “Vendor branches”). If you asked svn merge to compare the two
trees, you'd see the entire first tree being deleted, followed by an add
of the entire second tree! In these situations, you'll want svn merge to
do a path-based comparison only, ignoring any relations between files
and directories. Add the --ignore-ancestry option to your merge command,
and it will behave just like svn diff."
> To further hamper me along the way. After I'd done the failed merge, I used
> TortoiseSVN to revert the folder I had done the merge in. It restored the files,
> but a "svn status" still reported that changes had been made. I only found this
> out after I had become significantly balder ;-)
You'll have to show us details. (TortoiseSVN is a separate project, by
Note that 'svn revert -R' will remove textual and property changes, and
un-do any schedulings. But it will *not* delete unversioned things. So
if you have a bunch of stuff scheduled for addition, you'll end up with
a bunch of unversioned junk left behind after the recursive reversion.
Is this what you're talking about?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jul 1 01:40:31 2004