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

Re: [PATCH]: Was [PROPOSAL] Takeover Take 2

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-05-05 17:09:29 CEST

Julian Foad <julianfoad@btopenworld.com> wrote on 05/05/2006 08:07:48 AM:

> Paul Burba wrote:
> > "svn co --force URL WC_PATH" behaves exactly as "svn co URL WC_PATH"
> > now except when the co attempts to add some path PATH where URL/PATH
> > WC_PATH/PATH. In these cases there is an obstruction and these are
> > handled as follows:
> [8 cases described (not exactly "use cases" in the normal sense -
> )]

Hi Julian,

You're right, it's hardly a UML diagram. I simply wanted to document the
expected behavior of the patch in each possible obstruction scenario.

> [...]
> > I'm uncertain what the ideal behavior is in use cases E and G.
> What is the overall description of the new behavior, the concise summary
> its intent, from which the reader can mostly deduce or at least findit
> to understand and remember the behaviour in each case? Writing this
> would help
> you to answer your own questions about how it should behave in certain
> Please add this concise summary to the "svn checkout --help" output
> as part of your patch.

How does this sound?

checkout (co): Check out a working copy from a repository.
usage: checkout URL[@REV]... [PATH]

  If specified, REV determines in which revision the URL is first
  looked up.

  If PATH is omitted, the basename of the URL will be used as
  the destination. If multiple URLs are given each will be checked
  out into a sub-directory of PATH, with the name of the sub-directory
  being the basename of the URL.

  If --force is used, obstructing paths in the working copy destination
  do not automatically cause the check out to fail. If the obstructing
  is the same type (file or directory) as the corresponding path in the
  repository it will be left 'as-is' in the working copy. For directories
  simply means the obstruction is tolerated. For files, any content
  between the obstruction the repository are treated like a local
  to the working copy. All properties from the repository and applicable
  auto-props are applied to the obstructing path.

Obviously this still doesn't address what to do when an obstructing
directory is already versioned. Do you see how this could be a gray area?
 To me this doesn't seem likely scenario. If people agree it isn't, I'm
more than happy to make the co fail if any obstruction is already a
working copy.

> > A few people have mentioned that perhaps missing paths should be
> > for deletion and non-obstructing paths scheduled for addition. This
> > does neither as it wasn't in my original proposal and I wanted to keep

> > this first patch as simple as possible.
> To my mind, that would be an operation with a different and incompatible

> purpose, not an optional extension to the behaviour. Your goal is along
> lines of adding stuff from the repository to what is already present,


> > + _("Failed to takeover directory '%s': "
> One of my language bug-bears:
> If you must use the term "takeover" at all, when used as a verb as
> it is here,
> it should be two separate words: "I take over, you take over, he/she/it
> over, to take over, ...". (Not "It takeovers" or "It takesover".)

Ah, it does appear "takeover" is exclusively a noun - curse the dictionary
:-) I am completely open to using different language. Regardless, it
does seem we need a new term. Calling what is happening here an "add"
isn't accurate, it certainly isn't a merge, it is a bit update-esque but
not quite...any suggestions?


> Finally, I believe one of the goals should be that the sequence:
> svn import local-dir
> svn checkout URL local-dir --force
> should accomplish a conversion in place of the local dir to a WC,
> properties (from auto-props) and file types are present, and with no
> errors and
> no slew of warnings (maybe one warning at most). I'd like to see that
> explicitly listed as a goal (if you agree) and perhaps tested (if it
> already; I haven't read your tests).

Michael Sweet <mike@easysw.com> wrote on 05/05/2006 08:23:20 AM:
> +1 (not that I have a vote, but this is my most likely use case)

John Peacock <jpeacock@rowman.com> wrote on 05/05/2006 09:56:19 AM:
> +1 from me too (also non-voting), as long as the first step above is
> optional (since at least for me, there is usually already something in
> the repository that I don't want to overwrite).

There isn't a test for this specific scenario as I thought it's success
was implied by the other tests. If not I'll gladly add a new test.
Hopefully the 'concise summary' above now makes it clear that the patch
already handles this case, e.g.:

svnadmin create \SVN\REPOS\REPOSX

cat /SVN/config
enable-auto-props = yes

*.c = svn:eol-style=native

svn import /SVN/WCS/TO/WCX file:///svn/repos/REPOSX -m "initial import"
--config-dir /SVN
Adding \SVN\WCS\TO\WCX\Dir A
Adding \SVN\WCS\TO\WCX\Dir A\Dir A.B
Adding \SVN\WCS\TO\WCX\Dir A\Dir A.B\Doc A.txt
Adding \SVN\WCS\TO\WCX\Dir A\Doc A.txt
Adding \SVN\WCS\TO\WCX\Dir A\Dir A.A
Adding \SVN\WCS\TO\WCX\Dir B
Adding \SVN\WCS\TO\WCX\Dir C
Adding \SVN\WCS\TO\WCX\main.c
Adding \SVN\WCS\TO\WCX\Root Doc.txt

Committed revision 1.

svn co file:///svn/repos/REPOSX \svn\WCS\TO\WCX --force --config-dir /SVN
T \SVN\WCS\TO\WCX\Dir A\Dir A.B\Doc A.txt
T \SVN\WCS\TO\WCX\Dir A\Doc A.txt
T \SVN\WCS\TO\WCX\main.c
T \SVN\WCS\TO\WCX\Root Doc.txt
Checked out revision 1.

svn status -v \svn\WCS\TO\WCX
                1 1 Burba \SVN\WCS\TO\WCX
                1 1 Burba \SVN\WCS\TO\WCX\Dir A
                1 1 Burba \SVN\WCS\TO\WCX\Dir A\Dir A.B
                1 1 Burba \SVN\WCS\TO\WCX\Dir A\Dir A.B\Doc
                1 1 Burba \SVN\WCS\TO\WCX\Dir A\Doc A.txt
                1 1 Burba \SVN\WCS\TO\WCX\Dir A\Dir A.A
                1 1 Burba \SVN\WCS\TO\WCX\Dir B
                1 1 Burba \SVN\WCS\TO\WCX\Dir C
                1 1 Burba \SVN\WCS\TO\WCX\main.c
                1 1 Burba \SVN\WCS\TO\WCX\Root Doc.txt

svn pl "/SVN/WCS/TO/WCX/main.c"
Properties on '\SVN\WCS\TO\WCX\main.c':

svn pl "file:///svn/repos/REPOSX/main.c"
Properties on 'file:///svn/repos/REPOSX/main.c':

Paul B.

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 May 5 17:10:06 2006

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