Brandon Ehle <email@example.com> writes:
> Subversion is a tool, its supposed to make your project easier. If
> every time we want to merge unrelated files or directories we have to
> checkout 3 working copies and manually do a 3 way merge, Subversion
> isn't being very useful.
As far as I can tell, checking out (or exporting) 2 working copies and
then "handing off to diff" is exactly what Eric wants. I don't really
see how it works, but it seems to be what he wants.
As far as merge goes: I don't know what the merge equivalent of "hand
off to diff" is, but it would appear to involve checking out, or
exporting, 2 working copies in addition to the one receiving the
merge, and then doing "something".
A simple script doing "export; export; something;" will work just as
well as having Subversion do it. In fact if you are going to ignore
revision history and play games looking for matching filenames you are
probably better off implementing it in a language like perl or python
then you are writing it in C.
> >I guess the question I really have is: why you don't just ensure that
> >your files have the proper revision history? If they did, Subversion
> >would do what you want.
> Because the people on this list are not going to be the only people
> who use Subversion. Inevitably, you are going to run into a case
> where someone has been implementing vendor branches using imports,
> after all the first vendor branch was brought in using import, why
> wouldn't you bring in the second version of the vendor branch the same
> If its decided that Subversion won't support logical diffs between
> unrelated files, then we should at least make a specialized vendor
> import that automatically generates the ancestry, or the ability to
> create ancestry for files that currently have no ancestry at a later
Have you looked at tools/client-side/svn_load_dirs.pl?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Dec 8 19:27:39 2002