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

Re: [PATCH] new feature: takeover

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-08-19 15:17:58 CEST

kfogel@newton.ch.collab.net wrote on 08/18/2005 10:32:42 PM:

> Branko Čibej <brane@xbc.nu> writes:
> > >The original patch that I sent to this list does precisely that. I
> > >know if it meets the standards of the SVN crew, but the biggest
problem is
> > >of course that it is against the 1.2.0 tag, not head. If there is
> > >interest for the patch, I could put in the time to move the patch up
> > >head. I wouldn't want to do that if the core developers were going to
> > >reject it on philosophical grounds, though. Any votes? :-)
> > >
> > I don't think there were any objections to the concept.
> I for one no longer know exactly what the concept is, and would
> appreciate a pointer to the post describing it :-).

Here is the original post:


The thread is not that long. The original patch was for a new subcommand,
the discussion morphed into that this ought to just be a feature of
checkout. I believe that some even suggested it ought to be the default
behavior of checkout. If not, then some sort of switch.

Basically, the patch would allow svn checkout to "slide a working copy"
beneath an existing project. Picture all of those KDE developers that had
CVS working copies on their disks. They could have run an svn co on top
of that project. Currently, this will abort. With this patch, it would
create the working copy and leave any existing files alone. svn status
would then be able to figure out if they were modified.

I think everyone agreed that this part of the proposal was definitely a
good idea. Most of the discussion centered around whether it could be
made even better by using the existing local files to construct the
working copy (avoiding the new download). Of course it would have to have
logic to figure out if the local file and the repository file were the

I think what we are saying now, is let's try to get the original idea
implemented and then we can talk about making it better later.

We get a lot of requests in Subclipse that would require a feature like
this in Subversion in order to implement those requests, so this is
something I would personally like to see as it would allow me to close a
number of issues that are open in Subclipse.



Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 15:22:44 2005

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