At 05:10 AM 03/09/2005 +0200, you wrote:
>Regarding the need for an extra knob: the idea that checkout would just
>ignore existing files/dirs makes me uneasy. What if I check out to the
>wrong directory by mistake? Sure, my local files remain unchanged, but
>I'd have a hell of a week-end cleaning out the cruft :\
To be fair, this can happen with the existing 'checkout', in the event that
none of the existing files collides with a repository file. It would just
be one of those "Oh, shit" moments :-)
I think it's far more likely to accidentally do a 'checkout' (or
'takeover') into the wrong version of a given project, where the filenames
would mostly be the same anyway. In general, it would then suffice to 'rm
-rf .svn', which would be safe because the takeover could only succeed in
the first place in the case where the tree was not already under version
control.
>There is an alternative: put the takeover feature under "svn update
>URL". There's no new subcommand or switch, and no change in semantics
>because update doesn't take an URL parameter now. And I think that
>"update" is a fairly good mnemonic for this, i.e., "I have this tree
>I've just imported, now update it to a SVN working copy."
In my use case, though, this interpretation becomes "Update what used to be
a Visual SourceSafe working copy to be a SVN working copy", which tends to
imply (somewhat arrogantly) that SVN is more advanced than whatever you're
switching over from, and thus whatever it is, the conversion is an update,
or even, if the reader isn't well-informed, that SVN is a newer version of
VSS or P4 or CVS or whatever you're switching from. I mean, certainly the
feature could be hooked in pretty much anywhere, but I think if there's
going to be any argument over what language is used for it, then the
language that is chosen in the end had better match up with the true
underlying meaning of the command. The word "takeover" captured it best for
me, and adding a new command required less learning (and more copy/pasting
;-) for me than adding a switch to an existing command, which is why my
original patch adds it as "svn takeover".
My take on it is that if there is *any* chance that the command might, at
any time in the future, be updated to do more than simply disable the file
copy operation that is part of the implicit 'svn update' in 'svn checkout',
then it shouldn't be made into a "subfeature" of the "checkout" (or
"update") command. If it will ever try to save bandwidth in any way (either
by checksum testing, which you objected to, or an rsync-like feature, which
would have the same problem as checksum testing but be far less likely to
encounter it, or anything else), or more to the point if it will ever do
anything that 'svn checkout' does not do (by which I mean new
functionality, not omitting 'checkout's functionality), then it should be
its own command.
As for the safety of rsync, it is certainly possible for two completely
different blocks to have the same rolling & strong checksums; indeed, it is
mathematically impossible for there not to be at least 2^(n-m) conflicts
for block length n and combined checksum width m (in bits). However, the
probability of this for real-world data (data that must follow a pattern of
some kind, such as English text, source code, image data or structured
compressed data) is exceedingly low. The rsync tool itself is used in many
situations where a file becoming corrupted would be absolutely untenable,
and yet in all its years of use, it has never ever had a conflict (a
conflict would almost certainly be reported as a bug to the rsync dev
team). Also keep in mind that the block checksum comparisons are restricted
to a file, which means that the same *type* of data is being compared. This
leads to it being even more unlikely for a collision to occur, since the
more similar two blocks are, the less likely they are to have the same MD5
checksum. None of this matters at this point, though, as the general
consensus is not to incorporate the rsync code I am developing. :-)
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 3 06:54:34 2005