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

Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-04-14 22:15:37 CEST

John Peacock <jpeacock@rowman.com> wrote on 04/14/2006 04:07:35 PM:

> Paul Burba wrote:
> > Pouring over the takeover threads there seems to be a consensus that
> > checkout is the place for this functionality and that further
> > optimizations/improvements can wait. There is less agreement on the
> > question of whether co needs a new option --takeover, should use
--force,
> > or should just behave this way by default (my vote if for the last
> > option).
>
> Just to confuse the matter, I'm still of the opinion that checkout
should not
> silently absorb a pre-existing directory tree. I think that, although
that
> would be convenient for certain situations (I believe the Eclipse case
was
> mentioned repeatedly), it has the (to my mind) distinct disadvantage
that it
> loses information. Implicitely, conversion of a directory tree from
plain files
> to a working copy "loses" the information that this was not a working
copy to
> begin with.
>
> If the eventual result is that files with the same name/path as in the
> repository will be automatically "added" and changes from the repository
version
> will show up as [M]odified, that's one thing. But how would the various
WC
> special flags be interpreted:
>
> 1) a file on disk is executable, but in the repository isn't tagged as
> svn:executable, what happens?
>
> 2) the reverse of 1 (svn:executable is set but the existing file isn't)?
>
> 3) svn:ignores filters file out of the absorbed tree (this is probably
harmless
> since the file could be manually added when the ? status was noticed)?

My opinion was that these three things have to somewhat be non issues
because there is nothing stopping someone today from renaming a local
folder, checking out a project, and then copying everything over the top.
This is what Subclipse users wanted us to do for them (but we do not). If
someone did this, Subversion would deal with it. You could of course
argue that if you did this yourself you have to expect to suffer whatever
side-effects ensue, versus doing it via checkout.

> I'd personally advocate that --force be required to absorb existing
files into a
> in-place checkout, but it would be nice to have a .subversion/config
setting
> that made that the default (for those who wants it)...

I do not care if it requires --force or not. Subclipse can supply the
flag so long as JavaHL exposes it to us. I think it was ghudson, kfogel
and several others who thought this should be the default, without needing
--force. I happen to agree, but would not mind if there were a switch.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc 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 Apr 14 22:16:44 2006

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.