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

Re: the 'takeover' feature

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-09-03 04:19:08 CEST

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?

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 3 04:19:56 2005

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

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