Ben Collins-Sussman wrote:
>
> On Sep 2, 2005, at 6:46 PM, Greg Hudson wrote:
>
>>
>> I think turning an existing tree into a working copy is a corner case
>> and is too specialized to deserve very much code in our tree, if any.
>> If we're going to devote any code to it, it should not jump through
>> hoops to save network bandwidth, but should just download the text- base
>> files and use the existing files as working copy files.
>
>
> The current version of the patch in the issue does exactly this. It
> runs svn_ra_do_update() as usual (not conserving any network
> bandwidth), and unconditionally installs the incoming data as text-
> base. If it happens to notice an existing working file by the same
> name, then that working file's timestamp is recorded in the entires
> file, and the text-base isn't copied out to the user-visible area.
>
> All of this new behavior is done only if the newly-added "takeover"
> flag is passed to svn_client_checkout(). It sounds like you're
> advocating that we simply make this behavior the norm, rather than a
> triggerable thing...?
>
> The use case I'm trying to solve is newbies bootstrapping for the
> first time:
>
> $ svn import mytree svn://host/mytree
> $ svn checkout svn://host/mytree
> ==> obstruction errors
>
> I see this behavior frustrate newbies over and over. The first
> reaction is, "why didn't import convert my tree into a working copy?
> I have to redownload everything?!?" The second reaction is, "why the
> heck do I have to move the old tree out of the way?"
>
> I guess the current patch solves the second problem, although it
> doesn't really save much time. It's just means less frustration.
>
> Other opinions about this? Is the current patch in the issue
> sufficient?
I think it is. I'm uneasy about comparing checksums, because it _might_
happen that we get the same checksum for files with wildly different
content -- thus hosing not only the working copy, but potentially the
repository on further commits. Potential data corruption is potential
data corruption. (Note that we _never_ rely on checksums when we're
asking whether two files are identical. We only use them in the
repository for detecting file corruption that happens through "natural"
causes.)
As for saving bandwidth... I'm willing to bet that 99.9% of checkouts
does _not_ happen immediately after an import, newbies notwithstanding.
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 :\
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."
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 3 05:11:10 2005