Re: [PATCH] Allow copy files that already copied

Julian Foad wrote:
> That's not a precise enough description,
> but I accept that it could probably be
> fairly simple and easy to understand.

Right. I suck at explaining these things.

Just in case anyone wants to know what I meant, I'll try again.
Skip this entire posting if you already get it or don't care.. Seriously! :-)

From users POV, the WC is conceptually a filesystem that watch for
modifications. Users are aware that the WC is not watched live. From
a newbie's POV, changes are recorded when 'svn commit' is run.

Therefore it is not hard for a user to understand that two consecutive
file moves involving the same file will not be recorded as two
separate operations, because users regard the 'svn commit' as the
point in time when "recording differences" ultimately take place.

Developers know that 'svn mv' does in fact record various information
in a hidden directory, but many users can (and do) happily ignore
that.

(Which, I guess, is also why svn newbies often use filesystem
copy/move operations instead of svn cp/mv, but that's another story.)

> 1) Make the second copy/move refer to the source of the first one.
>
> 2) Make the second copy/move refer to the intermediate URL that does
> not yet exist (at least not with the required content) in the repository.

If I understand you correctly,

Approach 1) is similar to how the newbie svn user thinks.

Approach 2) however allows for more advanced work to be recorded
straight in the WC before a commit is required, eg.:

   svn cp a b
   ... edit file 'b' now ...
   svn cp b c
   ... edit file 'c' now ...
   svn commit

After commit, a HEAD vs. HEAD-1 diff on 'c' would correctly show diffs
to the modified 'b' file.
Whereas with approach 1), that diff would incorrectly show (much
larger) diffs against 'a'.

I dislike having to do more commits than I really want to on account
of the WC code lacking recording capabilities, so 2) is appealing.
OTOH, I'd definitely go with 1) if I had to code it myself =).

> OK, I haven't presented a specification or examined
> all the avenues, but I think this could well be done.

Can't thank you enough for describing the technical aspects,
my brain would've exploded had I tried.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 13 17:34:40 2005