You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Robert Whitaker <ca...@yahoo.com> on 2012/08/16 08:00:53 UTC
Creating sparse working copy retroactively from existing disjoint working copies
========
QUESTION
========
Is it possible to retroactively convert a "disjoint" working copy
into a "sparse" working copy?
=======
SUMMARY
=======
I have not been able to do this, and a new feature request may be
to add an "include" option to the --set-depth flag. The --set-depth
flag already has an "exclude" option so adding an "include" option
seems symmetric and may solve this problem.
==========
BACKGROUND
==========
I have tried doing this with the --set-depth and --force flags and I
can _ALMOST_ get it to work... but I have come to a dead end... I
have read the Subversion manual and I have searched previous posts...
Hopefully somebody on this list can point me to the right solution,
and if no solution exists, then maybe this can be turned into a
feature request for the "include" option.
=================
PROBLEM STATEMENT
=================
The following "statements" define the problem I am trying to solve:
---o---
STATEMENT 1:
---o---
Assume I have the following repository structure (the example was
borrowed from the Subversion manual):
mom/son
mom/son/grandson
mom/daughter
mom/daughter/granddaughter1
mom/daughter/granddaughter1/bunny1.txt
mom/daughter/granddaughter1/bunny2.txt
mom/daughter/granddaughter2
mom/daughter/fishie.txt
mom/kitty1.txt
mom/doggie1.txt
---o---
STATEMENT 2:
---o---
Assume I only care about "granddaughter1" as shown below:
mom/daughter/granddaughter1/bunny1.txt
mom/daughter/granddaughter1/bunny2.txt
---o---
STATEMENT 3:
---o---
Assume I didn't know about sparse checkouts (or about the --depth
flag) and assume I had created my working copy by creating all the
intermediary directories using "mkdir" as follows
$ mkdir -p /svn-test/mom/daughter
$ cd /svn-test/mom/daughter
$ svn co svn://REPOSITORY/mom/daughter/granddaughter1
A granddaughter1/bunny1.txt
A granddaughter1/bunny2.txt
Checked out revision 85792.
---o---
STATEMENT 4:
---o---
Of course, I can _NOT_ run "svn status" for the "mom" directory
because said directory is not part of the working copy:
$ svn status /svn-test/mom
svn: warning: '/svn-test/mom' is not a working copy
---o---
STATEMENT 5:
---o---
This is our problem statement: Assume I want to modify the above
working copy in-place and turn it into a sparse checkout. The end
result should be that I can run "svn status" from all intermediary
directories.
==================
ATTEMPTED SOLUTION
==================
In the steps below I attempt to solve our problem using the --depth
flag and I almost get it to work...
---o---
STEP 0:
---o---
For completeness, and for the benefit of those who may be following
these steps at home, here is the output of the "find" command which
shows the current directory structure:
$ find /svn-test
/svn-test
/svn-test/mom
/svn-test/mom/daughter
/svn-test/mom/daughter/granddaughter1
/svn-test/mom/daughter/granddaughter1/.svn
/svn-test/mom/daughter/granddaughter1/.svn/entries
/svn-test/mom/daughter/granddaughter1/.svn/prop-base
/svn-test/mom/daughter/granddaughter1/.svn/props
/svn-test/mom/daughter/granddaughter1/.svn/text-base
/svn-test/mom/daughter/granddaughter1/.svn/text-base/bunny1.txt.svn-base
/svn-test/mom/daughter/granddaughter1/.svn/text-base/bunny2.txt.svn-base
/svn-test/mom/daughter/granddaughter1/.svn/tmp
/svn-test/mom/daughter/granddaughter1/.svn/tmp/prop-base
/svn-test/mom/daughter/granddaughter1/.svn/tmp/props
/svn-test/mom/daughter/granddaughter1/.svn/tmp/text-base
/svn-test/mom/daughter/granddaughter1/bunny1.txt
/svn-test/mom/daughter/granddaughter1/bunny2.txt
---o---
STEP 1:
---o---
As expected running "svn status" does not work on "mom" yet:
$ svn status /svn-test/mom
svn: warning: '/svn-test/mom' is not a working copy
---o---
STEP 2:
---o---
In order to create our working copy "in-place" we first do an
svn "checkout" and set the --depth flag to empty for the "mom"
directory:
$ svn co --depth empty svn://REPOSITORY/mom /svn-test/mom
Checked out revision 85792.
---o---
STEP 3:
---o---
At this point, running "svn status" works OK on "mom", and it
correctly reports that "daugher" is unversioned. So far so good:
$ svn status /svn-test/mom
? /svn-test/mom/daughter
---o---
STEP 4:
---o---
The output of the "find" command is very encouraging and it shows
that "mom" is now an svn working copy directory and the "mom/.svn"
directory exists. All that we need to do is convince "mom" that
"daughter" is part of the working copy:
$ find /svn-test
/svn-test
/svn-test/mom
/svn-test/mom/.svn
/svn-test/mom/.svn/entries
/svn-test/mom/.svn/prop-base
/svn-test/mom/.svn/props
/svn-test/mom/.svn/text-base
/svn-test/mom/.svn/tmp
/svn-test/mom/.svn/tmp/prop-base
/svn-test/mom/.svn/tmp/props
/svn-test/mom/.svn/tmp/text-base
/svn-test/mom/daughter
/svn-test/mom/daughter/granddaughter1
/svn-test/mom/daughter/granddaughter1/.svn
/svn-test/mom/daughter/granddaughter1/.svn/entries
/svn-test/mom/daughter/granddaughter1/.svn/prop-base
/svn-test/mom/daughter/granddaughter1/.svn/props
/svn-test/mom/daughter/granddaughter1/.svn/text-base
/svn-test/mom/daughter/granddaughter1/.svn/text-base/bunny1.txt.svn-base
/svn-test/mom/daughter/granddaughter1/.svn/text-base/bunny2.txt.svn-base
/svn-test/mom/daughter/granddaughter1/.svn/tmp
/svn-test/mom/daughter/granddaughter1/.svn/tmp/prop-base
/svn-test/mom/daughter/granddaughter1/.svn/tmp/props
/svn-test/mom/daughter/granddaughter1/.svn/tmp/text-base
/svn-test/mom/daughter/granddaughter1/bunny1.txt
/svn-test/mom/daughter/granddaughter1/bunny2.txt
---o---
STEP 5:
---o---
Now that "mom" is an svn directory, we can use the "svn update"
command and set the --depth flag to empty for the "mom/daughter"
directory... our first attempt shows an error deliberately for
instructional purposes. The command fails because an unversioned
directory named "daughter" already exists:
$ svn update --depth empty /svn-test/mom/daughter
svn: Failed to add directory '/svn-test/mom/daughter': an unversioned
directory of the same name already exists
---o---
STEP 6:
---o---
We now try again but with the --force flag, and this works OK, and
I get the "E" status because svn recognizes that "daughter" was an
"Existing" directory:
$ svn update --depth empty --force /svn-test/mom/daughter
E /svn-test/mom/daughter
Updated to revision 85792.
---o---
STEP 7:
---o---
This current step is symmetric with STEP 3. In STEP 3 we were able
to run the "svn status" command on "mom", and it correctly reported
that "daugher" was unversioned. Now in STEP 7 we are able to run the
"svn status" command on "mom/daughter", and it correctly reports that
the "granddaughter1" directory is unversioned. So far so good:
$ svn status /svn-test/mom/daughter
? /svn-test/mom/daughter/granddaughter1
---o---
STEP 8:
---o---
This current step is symmetric with STEP 4. Once again, the output of
the "find" command is encouraging and it shows that "daughter" is now
an svn directory and all the intermediary ".svn" directories exist:
$ find /svn-test
/svn-test
/svn-test/mom
/svn-test/mom/.svn
/svn-test/mom/.svn/entries
/svn-test/mom/.svn/prop-base
/svn-test/mom/.svn/props
/svn-test/mom/.svn/text-base
/svn-test/mom/.svn/tmp
/svn-test/mom/.svn/tmp/prop-base
/svn-test/mom/.svn/tmp/props
/svn-test/mom/.svn/tmp/text-base
/svn-test/mom/daughter
/svn-test/mom/daughter/.svn
/svn-test/mom/daughter/.svn/entries
/svn-test/mom/daughter/.svn/prop-base
/svn-test/mom/daughter/.svn/props
/svn-test/mom/daughter/.svn/text-base
/svn-test/mom/daughter/.svn/tmp
/svn-test/mom/daughter/.svn/tmp/prop-base
/svn-test/mom/daughter/.svn/tmp/props
/svn-test/mom/daughter/.svn/tmp/text-base
/svn-test/mom/daughter/granddaughter1
/svn-test/mom/daughter/granddaughter1/.svn
/svn-test/mom/daughter/granddaughter1/.svn/entries
/svn-test/mom/daughter/granddaughter1/.svn/prop-base
/svn-test/mom/daughter/granddaughter1/.svn/props
/svn-test/mom/daughter/granddaughter1/.svn/text-base
/svn-test/mom/daughter/granddaughter1/.svn/text-base/bunny1.txt.svn-base
/svn-test/mom/daughter/granddaughter1/.svn/text-base/bunny2.txt.svn-base
/svn-test/mom/daughter/granddaughter1/.svn/tmp
/svn-test/mom/daughter/granddaughter1/.svn/tmp/prop-base
/svn-test/mom/daughter/granddaughter1/.svn/tmp/props
/svn-test/mom/daughter/granddaughter1/.svn/tmp/text-base
/svn-test/mom/daughter/granddaughter1/bunny1.txt
/svn-test/mom/daughter/granddaughter1/bunny2.txt
---o---
STEP 9:
---o---
In STEP 4 all that we needed to do was convince "mom" that "daughter"
was part of the working copy. We first attempted this in STEP 5 (but
we had a deliberate error) and we finally accomplished this using the
--force flag in STEP 6. In STEP 8 above all that we need to do is
convince "daughter" that "granddaughter1" part of the working copy,
and we will attempt this below in STEP 10:
---o---
STEP 10:
---o---
This current step is symmetric with STEP 6. We now use the --force
flag and we try to use "svn update" on the "granddaughter1" directory:
$ svn update --depth empty --force /svn-test/mom/daughter/granddaughter1
At revision 85792.
---o---
STEP 11:
---o---
Notice that I got the "E" status in STEP 6 because svn recognized
that "daughter" was an "Existing" directory, but notice I did NOT
get an "E" status in STEP 10 above on the "granddaughter1" directory.
This is where our problem starts... If I repeat STEP 7 and try to run
"svn status" on "daughter", it still shows that "granddaughter1" is
unversioned:
$ svn status /svn-test/mom/daughter/
? /svn-test/mom/daughter/granddaughter1
---o---
STEP 12:
---o---
I can modify STEP 10 to use "--depth infinity" since I truly want
all files inside "granddaughter1" but this doesn't work either. I
can _NOT_ connect "daughter" and "granddaughter1". I am basically
stuck!!!
===========
CONCLUSIONS
===========
---o---
CONCLUSION 1:
---o---
The behavior of svn is inconsistent between STEP 6 and STEP 10. In
STEP 6 I was able to tell "mom" that "daughter" was part of the
"mom" working copy, as shown below:
$ svn update --depth empty --force /svn-test/mom/daughter
E /svn-test/mom/daughter
Updated to revision 85792.
But in STEP 10 I can _NOT_ convince "daughter" that "granddaughter1"
is part of the "daughter" working copy, as shown below:
$ svn update --depth empty --force /svn-test/mom/daughter/granddaughter1
At revision 85792.
This is understandable because the state of the directories is
DIFFERENT in both steps. In STEP 6, the "daughter" directory is an
unversioned directory not part of any working copy, but in STEP 10,
the "granddaughter1" directory is _ALREADY_ a working copy itself.
---o---
CONCLUSION 2:
---o---
Due to the fact that "granddaughter1" was already a working copy
itself, the command in STEP 10 acted on "granddaughter1/.svn"
and it did _NOT_ add "granddaughter1" to "daughter/.svn"
---o---
CONCLUSION 3:
---o---
We need a way to tell the "daughter/.svn" working copy to include an
already existing working copy... All that we seem to be missing is we
need to connect the "daughter/.svn" information to the "granddaughter1"
directory.
=================
POSSIBLE SOLUTION
=================
---o---
SOLUTION 1:
---o---
Maybe this problem can be solved with a new "include" option for the
--set-depth flag. Said flag already has an "exclude" option so it would
seem natural (and symmetric) for it to have an "include" option.
For example if we had a consistent working copy we _COULD_ tell
"daughter/.svn" to "exclude" the "granddaughter1" directory as
follows:
$ svn update --set-depth exclude /svn-test/mom/daughter/granddaughter1
THEREFORE: One possible solution to this problem is to create a
new "include" option as follows:
$ svn update --set-depth include /svn-test/mom/daughter/granddaughter1
---o---
SOLUTION 2:
---o---
Another solution (which works but it is a total hack) is to delete the
"granddaughter1/.svn" directory and repeat STEP 10. This is a total
hack and it is presented here only for instructional purposes.
==================
ALTERNATE SOLUTION
==================
Of course there may be an alternate solution which uses existing svn
commands to solve this problem? I would be happy to hear from somebody
about how to solve this problem.
Thanks!
Re: Creating sparse working copy retroactively from existing
disjoint working copies
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Robert Whitaker wrote on Wed, Aug 15, 2012 at 23:00:53 -0700:
> ---o---
> STATEMENT 3:
> ---o---
> Assume I didn't know about sparse checkouts (or about the --depth
> flag) and assume I had created my working copy by creating all the
> intermediary directories using "mkdir" as follows
>
> $ mkdir -p /svn-test/mom/daughter
>
> $ cd /svn-test/mom/daughter
>
> $ svn co svn://REPOSITORY/mom/daughter/granddaughter1
> A granddaughter1/bunny1.txt
> A granddaughter1/bunny2.txt
> Checked out revision 85792.
>
> ---o---
> STATEMENT 5:
> ---o---
> This is our problem statement: Assume I want to modify the above
> working copy in-place and turn it into a sparse checkout. The end
> result should be that I can run "svn status" from all intermediary
> directories.
I don't think you have tried yet:
% svn co $REPOSURL/mom/daughter/granddaughter1 \
/svn-test/mom/daughter/granddaughter1
% svn co --depth empty $REPOSURL /svn-test
% svn up --parents --force /svn-test/mom/daughter/granddaughter1
Also note that the behaviour is likely to be different between 1.6 and
1.7 (the relevant portions of the library were reworked).
Re: Creating sparse working copy retroactively from existing disjoint working copies
Posted by Robert Whitaker <ca...@yahoo.com>.
> From: Johan Corveleyn <jc...@gmail.com>
> Sent: Thursday, August 16, 2012 2:38 AM
>
> [ snip ]
>
> Can you try:
>
> $ svn update --depth immediates /svn-test/mom/daughter
>
> That might connect granddaughter1 to daughter, with an E notification.
> It might also pull in other siblings of granddaughter1 of course, but
> only the directories themselves, not the entire subtrees.
>
Hello Johan,
Thanks for the reply... I tried using "immediates" but it did not work...
I tried using both "--depth" and "--set-depth" with different results but
neither worked. I have two copy-and-pasted sessions below. The first one
tries using "immediates", and the second is another "hack" which fools svn
into checking out the directory.
==========
SESSION #1: (using immediates)
==========
The following is a copy-and-pasted svn session which tries to solve
our problem using the "immediates" option:
---o---
$ # Confirm "svn status" does not recognize "granddaughter1"
$ svn status /svn-test-2/mom/
? /svn-test-2/mom/daughter/granddaughter1
$ # Try Johan's suggestion
$ svn update --depth immediates /svn-test-2/mom/daughter
At revision 85801.
$ svn status /svn-test-2/mom/
? /svn-test-2/mom/daughter/granddaughter1
$ # Ooops... the "svn status" command still fails as shown above
$ # Now try --set-depth
$ svn update --set-depth immediates /svn-test-2/mom/daughter
svn: Failed to add directory '/svn-test-2/mom/daughter/granddaughter1':
a versioned directory of the same name already exists
$ # Now try --set-depth with --force flag
$ svn update --set-depth immediates --force /svn-test-2/mom/daughter
svn: Failed to add directory '/svn-test-2/mom/daughter/granddaughter1':
a versioned directory of the same name already exists
$ # NOTE 1: svn recognizes "granddaughter1" is versioned
$ # NOTE 2: svn still fails to connect to "daughter"
$ # NOTE 3: We still have a problem!
---o---
==========
SESSION #2: (using hack to fool svn)
==========
The following is a copy-and-pasted svn session which solves
our problem using a "hack" to fool svn... it would be nice to
have an "official" way of fixing this problem:
---o---
$ # Made some local changes to "granddaughter1" as a test
$ svn status /svn-test-3/mom/daughter/granddaughter1
? /svn-test-3/mom/daughter/granddaughter1/bunny3.txt
M /svn-test-3/mom/daughter/granddaughter1/bunny2.txt
$ # Confirm "daughter" still not linked to "granddaughter1"
$ svn status /svn-test-3/mom/daughter
? /svn-test-3/mom/daughter/granddaughter1
$ # Move "granddaughter1" directory to fool svn
$ mv /svn-test-3/mom/daughter/granddaughter1 /svn-test-3/
$ svn status /svn-test-3/mom/daughter
$ # The "daughter" directory is now OK as shown by "svn status" above
$ # The "daughter" directory is empty because we moved "granddaughter1"
$ ls -al /svn-test-3/mom/daughter/
total 4
drwxr-xr-x+ 1 capnwhit Domain Users 0 Aug 16 10:59 .
drwxr-xr-x+ 1 capnwhit Domain Users 0 Aug 16 10:17 ..
drwxr-xr-x+ 1 capnwhit Domain Users 0 Aug 16 10:22 .svn
$ # Now repeat STEP 10 in original email with "--depth infinity"
$ svn update --depth infinity /svn-test-3/mom/daughter/granddaughter1
A /svn-test-3/mom/daughter/granddaughter1
A /svn-test-3/mom/daughter/granddaughter1/bunny1.txt
A /svn-test-3/mom/daughter/granddaughter1/bunny2.txt
Updated to revision 85801.
$ # It works as expected
$ # The "daughter" and "granddaughter1" are now connected
$ svn status /svn-test-3/mom/daughter
$ # Now we remove the recently added "granddaughter1"
$ rm -rf /svn-test-3/mom/daughter/granddaughter1/
$ # Verify that svn recognizes missing directory
$ svn status /svn-test-3/mom
! /svn-test-3/mom/daughter/granddaughter1
$ # Now we move back the safe "granddaughter1"
$ mv /svn-test-3/granddaughter1/ /svn-test-3/mom/daughter/
$ # Now svn recognizes the original "granddaughter1"
$ svn status /svn-test-3/mom
? /svn-test-3/mom/daughter/granddaughter1/bunny3.txt
M /svn-test-3/mom/daughter/granddaughter1/bunny2.txt
$ # NOTE 1: We can "hack" svn into connecting "granddaughter1"
$ # NOTE 2: It would be nice to have an official way to do this
---o---
Re: Creating sparse working copy retroactively from existing disjoint
working copies
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Aug 16, 2012 at 8:00 AM, Robert Whitaker <ca...@yahoo.com> wrote:
[ snip ]
> ==================
> ALTERNATE SOLUTION
> ==================
> Of course there may be an alternate solution which uses existing svn
> commands to solve this problem? I would be happy to hear from somebody
> about how to solve this problem.
Can you try:
$ svn update --depth immediates /svn-test/mom/daughter
?
That might connect granddaughter1 to daughter, with an E notification.
It might also pull in other siblings of granddaughter1 of course, but
only the directories themselves, not the entire subtrees.
(I still like your "include" idea though, so it may be a good feature
request. But the above might be a workaround ... if it works.)
--
Johan
Re: Creating sparse working copy retroactively from existing
disjoint working copies
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Robert Whitaker wrote on Fri, Aug 17, 2012 at 08:45:32 -0700:
> ----- Original Message -----
> > From: Daniel Shahaf <d....@daniel.shahaf.name>
> > Sent: Friday, August 17, 2012 10:03 AM
> >
> > % mkdir d
> > % cd d
> > % mkdir notes notes/commit-access-templates
> > % svn co -q
> > http://svn.apache.org/repos/asf/subversion/trunk/notes/commit-access-templates/
> > notes/commit-access-templates/
> > % svn co -q --force http://svn.apache.org/repos/asf/subversion/trunk/ ./
> >
> > I don't have a recent build to test with (and the behaviour might have
> > changed at some point), but the above is what I try first.
> >
> > Does that answer your question?
> >
>
> Hello Daniel,
>
> Thanks for the reply. I am running 1.6.17 and the above sequence of commands
> did not work. The second "checkout" failed even with the --force flag. I
> show a copy-and-pasted session below showing my failed attempt.
>
> Even if the second "checkout" had succeeded, it would have just created a full
> checkout of the tree under "trunk" but what I was interested in originally was
> in creating a "sparse" checkout (not a "full" checkout).
>
Sorry, missed that detail.
> I am still curious if a sparse checkout is possible retroactively, so if you
> have any further insights I would appreciate further comments. The example I
> showed in my original post is _VERY_ easy to reproduce in your own repository
> locally if you want to play around and test possible solutions.
>
Unfortunately I can't easily test solutions as I don't have a moderately
recent 1.7.x or trunk build at the moment.
Re: Creating sparse working copy retroactively from existing disjoint working copies
Posted by Robert Whitaker <ca...@yahoo.com>.
----- Original Message -----
> From: Daniel Shahaf <d....@daniel.shahaf.name>
> Sent: Friday, August 17, 2012 10:03 AM
>
> % mkdir d
> % cd d
> % mkdir notes notes/commit-access-templates
> % svn co -q
> http://svn.apache.org/repos/asf/subversion/trunk/notes/commit-access-templates/
> notes/commit-access-templates/
> % svn co -q --force http://svn.apache.org/repos/asf/subversion/trunk/ ./
>
> I don't have a recent build to test with (and the behaviour might have
> changed at some point), but the above is what I try first.
>
> Does that answer your question?
>
Hello Daniel,
Thanks for the reply. I am running 1.6.17 and the above sequence of commands
did not work. The second "checkout" failed even with the --force flag. I
show a copy-and-pasted session below showing my failed attempt.
Even if the second "checkout" had succeeded, it would have just created a full
checkout of the tree under "trunk" but what I was interested in originally was
in creating a "sparse" checkout (not a "full" checkout).
I am still curious if a sparse checkout is possible retroactively, so if you
have any further insights I would appreciate further comments. The example I
showed in my original post is _VERY_ easy to reproduce in your own repository
locally if you want to play around and test possible solutions.
For completeness of the archive, I show my failed copy-and-pasted session
below.
=======================
COPY-AND-PASTED SESSION
=======================
---o---
$ # Show my current directory
$ pwd
/svn-temp
$ # Directory is empty as shown by "find" below
$ find
.
$ # Try suggested commands, starting with mkdir
$ mkdir d
$ cd d
$ mkdir notes notes/commit-access-templates
$ svn co -q http://svn.apache.org/repos/asf/subversion/trunk/notes/commit-access-templates/
notes/commit-access-templates/
$ # So far so good... first checkout successful as shown by "find" below
$ find
.
./notes
./notes/commit-access-templates
./notes/commit-access-templates/.svn
./notes/commit-access-templates/.svn/all-wcprops
./notes/commit-access-templates/.svn/entries
./notes/commit-access-templates/.svn/prop-base
./notes/commit-access-templates/.svn/prop-base/contrib-committer.tmpl.svn-base
./notes/commit-access-templates/.svn/prop-base/full-committer.tmpl.svn-base
./notes/commit-access-templates/.svn/prop-base/partial-committer.tmpl.svn-base
./notes/commit-access-templates/.svn/prop-base/pmc-member.tmpl.svn-base
./notes/commit-access-templates/.svn/props
./notes/commit-access-templates/.svn/text-base
./notes/commit-access-templates/.svn/text-base/contrib-committer.tmpl.svn-base
./notes/commit-access-templates/.svn/text-base/full-committer.tmpl.svn-base
./notes/commit-access-templates/.svn/text-base/partial-committer.tmpl.svn-base
./notes/commit-access-templates/.svn/text-base/pmc-member.tmpl.svn-base
./notes/commit-access-templates/.svn/tmp
./notes/commit-access-templates/.svn/tmp/prop-base
./notes/commit-access-templates/.svn/tmp/props
./notes/commit-access-templates/.svn/tmp/text-base
./notes/commit-access-templates/contrib-committer.tmpl
./notes/commit-access-templates/full-committer.tmpl
./notes/commit-access-templates/partial-committer.tmpl
./notes/commit-access-templates/pmc-member.tmpl
$ # Now we try second "checkout" command
$ svn co -q --force http://svn.apache.org/repos/asf/subversion/trunk/ ./
svn: Failed to add directory 'notes/commit-access-templates': a versioned directory of
the same name already exists
$ # Whooops... command failed even with --force flag
$ svn --version --quiet
1.6.17
$
---o---
Re: Creating sparse working copy retroactively from existing
disjoint working copies
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Robert Whitaker wrote on Wed, Aug 15, 2012 at 23:00:53 -0700:
> ========
> QUESTION
> ========
> Is it possible to retroactively convert a "disjoint" working copy
> into a "sparse" working copy?
% mkdir d
% cd d
% mkdir notes notes/commit-access-templates
% svn co -q http://svn.apache.org/repos/asf/subversion/trunk/notes/commit-access-templates/ notes/commit-access-templates/
% svn co -q --force http://svn.apache.org/repos/asf/subversion/trunk/ ./
I don't have a recent build to test with (and the behaviour might have
changed at some point), but the above is what I try first.
Does that answer your question?