[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: Alan Barrett <apb_at_cequrux.com>
Date: 2006-04-16 11:30:34 CEST

On Sat, 15 Apr 2006, Mark Phippard wrote:
> There seems to be general agreement that svn checkout should just work
> this way be default, with a few people suggesting it should require
> the --force argument. Assuming one of these option is what ultimately
> gets implemented, what option would you suggest being added to make it
> work the way you want? It just seems like it would be hard to come up
> with anything that would gather much support.

My use case is: I have multiple machines that are supposed to have
identical versions of various files, but in reality they diverged long
before subversion entered the picture. I put the files from one machine
into a subversion repository; then I go to a second machine and do the
"takeover" dance; then I use "svn status" and "svn diff" to see how
different the second machine was from the first, and fix the differences
however I choose (sometimes by updating the machine from the repository,
and sometimes by updating the repository from the machine). Repeat
until all machines are in sync.

The "takeover" that I described is not something that I would want very
often, and it seems inappropriate for it to be either the default or
controlled by --force. Something like --only-metadata or --takeover
might work. Or I can continue to do it by copying .svn directories
around.

I think it would be wrong for anything with "takeover" in its name
to create, modify, or delete any files (except in .svn directories).
However, I think it would be fine for "checkout --force" to create
files.

--apb (Alan Barrett)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 16 11:31:52 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.