Re: Merging confuses renamed files

At 2:53 PM -0500 8/22/03, John Goerzen wrote:
>
>I don't quite follow your question, but I can state that from the
>example, "." is *NOT* a working copy of http://foo.com/somewhere. It
>could be a working copy at file:///home/alice/alicerepos.

Wait, I'm all confused.

A "working copy" is the files you think you have, on your disk.
There are some .svn/ directories scattered about, that are
Subversion-specific stuff, but basically it's "your files"--your
foo.c and bar.html and whatever. We address the working copy by
simple file-name things like "foo.c" or "~/src/whatever."

A "repository" is the files on the *server*'s disk. It's a database:
it has contents with names like "db/" and "hooks/", regardless of
what files you have. We address things in the repository with URLs,
like "http://host/dir/dir/" or "file:///home/alice/whatever".

So when you say "a working copy at file:///home/alice/alicerepos", I
think you really mean "a repository there." Yes?

> > In that case, I think the answer to your question is "Subversion does
>> not maintain history between repositories." The fact that Sue's
>> foo.py once came from Bob's is not recorded; the merge only knows that
>> Bob has a "bar.py," and Sue does not.
>
>I understand that. But both the "before" and the "after" for the
>merge come from Bob and are being recorded in Sue's repository. That
>is, svn merge knows that this is a rename and -- even though it has no
>idea where the wc data originated -- should execute the same operation
>locally to apply it.

You're saying "it could do this." I agree with that.

I'm saying "it doesn't do this." I think you agree with that ...
that's what got you started!

If the question is "why doesn't it do this?" then the answer is
"because it was not a design goal." Put another way, SVN is trying
to replace CVS, not Bitkeeper.

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org