[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moving a moved file

From: Folker Schamel <schamel23_at_spinor.com>
Date: 2003-12-26 21:09:29 CET

Ben Collins-Sussman wrote:
> svn cp A B
> svn cp A C
> svn commit
>
> and
>
> svn cp A B
> svn cp B C
> svn commit
>
> In both cases, B and C will claim to be direct descendants of A. Is
> that really okay? In the second scenario, is it really okay that B and
> C are siblings, rather than ancestor/descendant relationship? Doesn't
> that bother you?

No.
In contrary, I think it SHOULD work in that way. See below.

Francois Beausoleil wrote:
> In my opinion, the real intent here when we do multiple copies should be
> that B is a descendant of A, and C is a descendant of B. I would expect
> svn log --verbose to tell me that.

I don't agree because of the following:

The philosophy of a version control system is
to only store local changes AT COMMIT TIME,
but NOT remember the history how local changes exactly
have been archieved BETWEEN two commits.
This is how Subversion works for the file contents,
and therefore this is how Subversion also should work
for directory structure changes, too.
The result of "copy A B; copy B C" and "copy A B; copy A C"
is exactly the same at your harddisk, so it should
also the same for subversion.

For example, consider the following scenario:
1) Open a versioned text file in an text editor.
2) Add two lines XXX and YYY
3) Save the file
4) Delete the line XXX again
5) Save the file again
6) svn commit
The respository (including svn log, svn diff) will contain
EXACTLY the same result as when doing the following:
1) Open a versioned text file in an text editor.
2) Add one line YYY
3) Save the file
4) svn commit
The local history is different, but at commit time,
the resulting wc is the same.
In both cases, svn diff PREV:HEAD will tell you
that the line YYY was inserted, but NOT that XXX YYY
was inserted and XXX deleted again.
In other words, when committing, the LOCAL history
how the resulting change was archived does not matter.
The only things what matters is the wc state
at commit time.
For everyone this behaviour is natural,
so why should there be a problem that
copy A B; copy B C
is exactly equivalent to
copy A B; copy A C ?
In both cases, the result is the same at commit time,
namely there are two new files B and C which are a copy of A.

If you really want for some reason that Subversion
remembers that there was a line XXX for some time,
or that C is a copy if B which is a copy of A,
then you can and should use an intermediate commit.

BTW, currently "copy A B; copy B C" is not possible at all.
Therefore, allowing it and being equivalent to
"copy A B; copy A C" cannot be worse,
therefore what is the problem?
On the other hand, it would trivially solve several
problems, including the "move a/ b/; move b/a b/b" problem.
Without having to introduce atomic moves or other
unnecessary things.

Cheers,
Folker

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 26 21:11:30 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.