> > wasn't broken I'd give you the link), but it basically boils down
> > to this question: when merging in a revision that, in the source
> > repository, created a new file "file2" via a copy-with-history of
> > revision XXX of "file1", what revision YYY of "file1" in the
> > (different) target repository should the new "file2" in the target
> > repository be a copy of?
> I understand the goal (I've been reading the thread). What I don't
> understand is why non-head revisions are special. Any representation
> of copy history from a different repository has to include both the
> original repository and revision in that repository. No revision in
> the target repository would be appropriate.
I'm not sure if this answers your question (I'm not sure I fully
understand it) but here's a try...
I think some would say that there can be an "appropriate" revision in
the target repo to be the basis of the copy that's not the head revision.
For example, suppose revision 10 in source repo created 'foo', then
revision 20 in source repo modified 'foo', then revision 30 in
source repo copied 'foo' rev 10 to create 'bar'.
Now suppose source revision 10 was merged into target repo in
revision 100, and revision 20 was merged into target repo in revision
Now, suppose you want to merge in source repo revision 30 into the
target repo. Ideally, in the target repo, the creation of 'bar'
would be based on revision 100 of 'foo', not revision '200', as
this would be the most accurate mirroring of the source repo events
in the target repo.
To make the example more crisp, suppose that in the source repo
'foo' went from a MSWord document to a Latex document in revision
20. Then if you base 'bar' in the target repo off revision 200, then
the history of 'bar' in the target repo will show that it started
life as a Word document, was a Latex document for a while, then
went back to being a Word document, which is not really true.
I'm saying: "So what, let's just get svn merge working from multiple
repositories even with this flaw".
Archie Cobbs * CTO, Awarix * http://www.awarix.com
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 18 22:01:26 2004