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

Re: Takeover Take 2 Was: Re: the 'takeover' feature

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2006-04-23 13:16:02 CEST

Molle Bestefich wrote:
> Mark Phippard wrote:
>
>>We just need a way to do it. Paul is going in the direction
>>he is because that is what the committers indicated they
>>wanted back when this first came up.
>
> That's great.
>
> For reasons already mentioned, I'd like the takeover functionality to
> only slide metadata into the directory structure. If one needs files
> checked out too it can be done with 'svn update' afterwards.
>
> I'd like to propose that the command be named either:
[...]
> Any commiters willing to comment?

Yes, but I'm not going to discuss the naming until we're absolutely clear about
what we want the command to do.

It's clear that enough people want to be able to do this sort of thing -
connect an existing local copy to a repository. It's time we had a written
design proposal to consider.

We should look at the big picture: see how this operation fits into the set of
things that Subversion does, and design a solution that is capable of
addressing the "import + checkout in place" scenario as well as the "connect
this local non-WC tree to its repository" scenario.

* Create a local copy from a repository project:

   repos-proj -> repos-proj + local-proj
                     (disconnected)

     Existing solution: "svn export"

   repos-proj -> repos-proj + local-proj-WC
                     (connected)

     Existing solution: "svn checkout"

* Create a repository project from a local copy:

   local-proj -> repos-proj + local-proj
                     (disconnected)

     Existing solution: "svn import"

   local-proj -> repos-proj + local-proj-WC
                     (connected)

     Solution wanted. Suggest fundamentally a two-step method, "svn import" +
something like "svn takeover" (command name and syntax to be decided), though a
single-step UI would be convenient in addition. In this method, the "takeover"
step doesn't have to deal with any added/modified/deleted files (as long as it
fetches the same revision that the "import" step created).

* Connect a local project to a repository project, making it into a WC:

   repos-proj + local-proj -> repos-proj + local-proj-WC
     (disconnected) (connected)

     Solution wanted. Suggest this be the fundamental "takeover" operation.
Details about mis-matching files to be discussed below.

* Permanently disconnect a WC from its repos (like exporting in place):

   repos-proj + WC -> repos-proj + local-proj
     (connected) (disconnected)

     Explicit support for this operation might be a good idea in the end, but
need not be addressed now - it's probably uncommon enough that the work-around
(deleting the ".svn" directories") is acceptable. It's worth considering
whether such a command might be a direct counterpart to the one that connects a
local copy to a repository (e.g. "svn connect" and "svn disconnect").

ADDED/MODIFIED/DELETED FILES

Briefly, since we'd clearly expect the newly connected WC to have local file
differences reported by "svn status" as "locally Modified" (rather than
"unknown" or "broken"), it is logical to have missing files reported as
"Deleted" and extra files as "Added".

Should the local files' properties be as "import" or "add" would have set them,
and any differences from the repos marked as "Modifications", or do we need a
way to say "Get all props from the repos"?

Are there any other edge cases to consider?

It would be great if someone could write up a draft proposal with the complete
syntax (picking a particular command name to make it a concrete proposal),
semantics (especially the difficult stuff about mis-matching files/properties),
and simple examples of its use in each of the two main scenarios ("import" and
"connect").

- Julian

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