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"
does
> > 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 -
>
http://alistair.cockburn.us/crystal/articles/o/ucai/usecasealternateintro.html
> )]
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
of
> its intent, from which the reader can mostly deduce or at least findit
easier
> 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
cases.
>
> 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
path
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
this
simply means the obstruction is tolerated. For files, any content
differences
between the obstruction the repository are treated like a local
modification
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
scheduled
> > for deletion and non-obstructing paths scheduled for addition. This
patch
> > 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
the
> lines of adding stuff from the repository to what is already present,
Agreed.
> > + _("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
takes
> 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?
"seize/seizure"?
> 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,
whatever
> 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
isn't
> 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
[miscellany]
enable-auto-props = yes
[auto-props]
*.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
T \SVN\WCS\TO\WCX\Dir A\Dir A.B
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\Dir A\Dir A.A
T \SVN\WCS\TO\WCX\Dir B
T \SVN\WCS\TO\WCX\Dir C
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
A.txt
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:eol-style
svn pl "file:///svn/repos/REPOSX/main.c"
Properties on 'file:///svn/repos/REPOSX/main.c':
svn:eol-style
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