Re: Creating sparse working copy retroactively from existing disjoint working copies
Robert Whitaker wrote on Fri, Aug 17, 2012 at 08:45:32 -0700: > - Original Message - > > From: Daniel Shahaf > > 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
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 > Agranddaughter1/bunny1.txt > Agranddaughter1/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).
Corrupt .svn directory using Subversion 1.7
I am using Subversion 1.7.0. I wanted to exclude a directory from my working copy so I entered "svn update --set-depth exclude foodir". In the middle, I decided to cancel this operation. Now I'm in a state where some files under foodir are missing but SVN thinks all of the files are there. I tried to do a 'svn revert' and 'svn checkout' but nothing happens because it thinks the files are already there. 'svn status' thinks nothing has changed but 'svn ls' shows that some files/directories are missing from my working copy. Prior to Subversion 1.7, I would have been able to simply remove the .svn directory /in that directory/ and check out the files again. But now, I have to remove the .svn directory at the top level and check out all of the files again. The repository is huge so I want to avoid that, and plus all of my timestamps on the files/directories would be updated which is undesirable. Is there a simpler workaround? Is it possible to just fix or just re-checkout the files for that directory? -Steven
AW: Corrupt .svn directory using Subversion 1.7
Hi, Steven, Von: Steven Lee [mailto:stlee...@gmail.com] > I am using Subversion 1.7.0. I wanted to exclude a directory from my working > copy so I entered "svn update --set-depth exclude foodir". In the middle, I > decided to cancel this operation. Now I'm in a state where some files under > foodir are missing but SVN thinks all of the files are there. I tried to do > a 'svn revert' and 'svn checkout' but nothing happens because it thinks the > files are already there. 'svn status' thinks nothing has changed but 'svn > ls' shows that some files/directories are missing from my working copy. > Prior to Subversion 1.7, I would have been able to simply remove the .svn > directory in that directory and check out the files again. But now, I have > to remove the .svn directory at the top level and check out all of the files > again. The repository is huge so I want to avoid that, and plus all of my > timestamps on the files/directories would be updated which is undesirable. > Is there a simpler workaround? Is it possible to just fix or just > re-checkout the files for that directory? Did ou try "svn update --set-depth infinity foodir"?
Re: Corrupt .svn directory using Subversion 1.7
Guten Tag Steven Lee, am Sonntag, 19. August 2012 um 17:08 schrieben Sie: > I am using Subversion 1.7.0. I wanted to exclude a directory from my > working copy so I entered "svn update --set-depth exclude foodir". In > the middle, I decided to cancel this operation. Now I'm in a state > where some files under foodir are missing but SVN thinks all of the > files are there. --set-depth exclude foodir should have prevented the whole folder from being updated, so if it's there it's because of a former checkout and it's contents will be ignored because you told the working copy to do so. What are you really trying to achieve? Do you want foodir being updated or not? > I tried to do a 'svn revert' and 'svn checkout' but > nothing happens because it thinks the files are already there. svn checkout won't work in a already existing working copy and svn revert --recursive . will revert only those files missing besides those you excluded in foodir. > 'svn > status' thinks nothing has changed but 'svn ls' shows that some > files/directories are missing from my working copy. Please provide exact error messages as at least I don't seem to understand what/where your problem is depending on what you actually want to do. > Prior to Subversion 1.7, I would have been able to simply remove the > .svn directory /in that directory/ and check out the files again. If you really did a checkout you created two distinct working copies, which may or may not work as expected. You should have used at least update and even with that if you just have deleted the .svn directory you would have got conflicts with maybe already existing files and directories. I doubt this was ever an supported use case. > But > now, I have to remove the .svn directory at the top level and check out > all of the files again. No, you can always update and provide a new value for --set-depth or just use the --depth arg. See svn help update for details. > The repository is huge so I want to avoid that, > and plus all of my timestamps on the files/directories would be updated > which is undesirable. Backup the files including the timestamps, update your working copy and copy the the backups over again. > Is there a simpler workaround? Is it possible to > just fix or just re-checkout the files for that directory? svn update --set-depth inifinity will update your working copy and foodir. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: AW: Corrupt .svn directory using Subversion 1.7
Yes, I tried "svn update --set-depth infinity" and nothing happened. Many of the files are still missing from my working copy. It does seem like that should have worked. On a related note, I am able to "svn checkout ... foodir" elsewhere, and all of the files under foodir are retrieved. It's just when I do the same command under that directory that I can't seem to get the files. -Steven On Aug 19, 2012 11:32 PM, "Markus Schaber" wrote: > Hi, Steven, > > > Von: Steven Lee [mailto:stlee...@gmail.com] > > > I am using Subversion 1.7.0. I wanted to exclude a directory from my > working copy so I entered "svn update --set-depth exclude foodir". In the > middle, I decided to cancel this operation. Now I'm in a state where some > files under foodir are missing but SVN thinks all of the files are there. > I tried to do a 'svn revert' and 'svn checkout' but nothing happens > because it thinks the files are already there. 'svn status' thinks nothing > has changed but 'svn ls' shows that some files/directories are missing from > my working copy. > > > Prior to Subversion 1.7, I would have been able to simply remove the > .svn directory in that directory and check out the files again. But now, I > have to remove the .svn directory at the top level and check out all of the > files again. The repository is huge so I want to avoid that, and plus all > of my timestamps on the files/directories would be updated which is > undesirable. Is there a simpler workaround? Is it possible to just fix or > just re-checkout the files for that directory? > > Did ou try "svn update --set-depth infinity foodir"? > > > >
Re: AW: Corrupt .svn directory using Subversion 1.7
On Aug 19, 2012 11:45 PM, "Steven Lee" wrote: > > Yes, I tried "svn update --set-depth infinity" and nothing happened. Many of the files are still missing from my working copy. It does seem like that should have worked. > Just to be clear, I tried "svn update --set-depth infinity" in the foodir directory and "svn update --set-depth infinity foodir" in foodir's parent directory. > On a related note, I am able to "svn checkout ... foodir" elsewhere, and all of the files under foodir are retrieved. It's just when I do the same command under that directory that I can't seem to get the files. > > -Steven
