Re: Subversion Exception in 1.7.1/2
4073 says this is supposed to have been fixed. I'm now on 1.7.5 and still have the same issue. I can't use a relative path cos that is not where the libray is. I need absolute because some apps (viz VS 2010) require absolute paths for library references. I have to put the libraries on the C drive so that they can be accessed by any user without them having to change the VS settings. Daft thing is, it does actually check out the external library - I just get a MS exception report. I then have to do a cleanup and on subsequent updates I don't get the exception. If this is not fixed then every user has to edit user specific VS settings whenever my project is checked out by them. The settings are then wrong for everybody else when it gets checked back in! On Monday, 12 December 2011 13:04:47 UTC, Philip Martin wrote: > > coolie writes: > > > I am checking out a svn folder to Windows desktop, but have set the > > svn:externals property on this folder to check out a lib at C:/lib: > > > > svn:externals C:/lib > > This is issue 4073: > > http://subversion.tigris.org/issues/show_bug.cgi?id=4073 > > use a relative path such as "lib" rather than "C:/lib". > > -- > Philip > >
Re: Parallel branches/tags/trunk directories
I have exactly the same issue - I want to inhibit checkout of all tags (and branches) folders, but still be able to do an update from the root. I've read the replies on this post and none seem to solve the problem. Did you find a simple solution? Ideally this should be a property set on the root folder a bit like svn:ignore so that it is registered at the server. Looks like I'll just have to bite the bullet and write a co script that everyone has to run to do the initial checkout (don't have Python or Perl). I don't know where the depth information is held for each folder - maybe there is some way of modifying this file? As I understand it you would do the following: - checkout root (immediate files and folders only, which includes the script) - run the script, which would do the remaining checkout (but only the immediate children of tags or branches folders) - updating the root hereafter will not update sub-folders of tags or branches folders Also need a script to modify the tree for existing checkouts. This would delete the tags sub-folder contents from the local disk and set the co depth On Thursday, 11 August 2011 15:27:42 UTC+1, Mike Cepek wrote: > > (I did some searching for an answer here and elsewhere, and didn't find > it; sorry if I missed it.) > > The project I'm dealing with has the SVN repository arranged like so: > > proj/top1/branches/ > proj/top1/tags/ > proj/top1/trunk/ > proj/top2/common/branches/ > proj/top2/common/tags/ > proj/top2/common/trunk/ > proj/top2/thingA/branches/ > proj/top2/thingA/tags/ > proj/top2/thingA/trunk/ > proj/top2/thingB/branches/ > proj/top2/thingB/tags/ > proj/top2/thingB/trunk/ > proj/top2/deploy/common/branches/ > proj/top2/deploy/common/tags/ > proj/top2/deploy/common/trunk/ > proj/top2/deploy/thingA/env1/branches/ > proj/top2/deploy/thingA/env1/tags/ > proj/top2/deploy/thingA/env1/trunk/ > proj/top2/deploy/thingA/env2/branches/ > proj/top2/deploy/thingA/env2/tags/ > proj/top2/deploy/thingA/env2/trunk/ > proj/top2/deploy/thingB/env1/branches/ > proj/top2/deploy/thingB/env1/tags/ > proj/top2/deploy/thingB/env1/trunk/ > (etc) > > First, I completely agree that this organization has issues. Changing is > isn't an option. I'll spare you the details. :-/ > > My question is: how to checkout and update at the proj/ level without > getting the content of all the tags/ and branches/ directories? > > The "Sparse Directories" features of SVN (--depth and --set-depth) sounded > good: > http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html > > But those features are not sufficient. In order to do a fresh checkout of > the above and avoid the massive on-disk redundancy that would occur due to > the content of tags/ and branches/, each trunk/ directory must be checked > out individually. Other than creating a brittle script that lists each > trunk/ directory, I don't see a solution. Even then, each branches/ and > tags/ directory needs to be marked with --set-depth as well. > > I also discovered that "svn co URL/proj/top1 --depth immediates" can take > a very long time for a tree with tons of content. Seems like a bug (using > SlikSvn 1.6.15). Similarly, something like "svn update URL/proj/top1/tags > -depth immediates" would be handy at times to get just the empty > subdirectories, named after each branch or tag. Updating just one of those > subdirectories would allow mass-diffs between the trunk or another > branch/tag. I don't see why a depth-limited operation like that should > take so much time. > > I though about using 'svn list http://.../proj/' and grep'ing the result > for "/trunk", but that one command takes over 10 minutes - not feasible. A > checkout of all the trunk/ directory contents only takes 2.5 minutes. > > So: has anyone found a clean way to handle checkouts and updates when > branches/tags/trunk directories are strewn all over a tree? Thanks. > On Thursday, 11 August 2011 15:27:42 UTC+1, Mike Cepek wrote: > > (I did some searching for an answer here and elsewhere, and didn't find > it; sorry if I missed it.) > > The project I'm dealing with has the SVN repository arranged like so: > > proj/top1/branches/ > proj/top1/tags/ > proj/top1/trunk/ > proj/top2/common/branches/ > proj/top2/common/tags/ > proj/top2/common/trunk/ > proj/top2/thingA/branches/ > proj/top2/thingA/tags/ > proj/top2/thingA/trunk/ > proj/top2/thingB/branches/ > proj/top2/thingB/tags/ > proj/top2/thingB/trunk/ > proj/top2/deploy/common/branches/ > proj/top2/deploy/common/tags/ > proj/top2/deploy/common/trunk/ > proj/top2/deploy/thingA/env1/branches/ > proj/top2/deploy/thingA/env1/tags/ > proj/top2/deploy/thingA/env1/trunk/ > proj/top2/deploy/thingA/env2/branches/ > proj/top2/deploy/thingA/env2/tags/ > proj/top2/deploy/thingA/env2/trunk/ > proj/top2/deploy/thingB/env1/branches/ > proj/top2/deploy/thingB/env1/tags/ > proj/top2/deploy/thingB/env1/trunk/ > (etc) > > First, I completely agree that this organ
Feature request: inhibiting checkout for tags and branches
I have an inherited repo structure that has many projects with their own tags and branches folders. Users check out the whole structure as there are common lib references etc, but don't need to see the full contents of tags or branches folders, which can be massive. I would like a property svn:inhibit similar to svn:ignore set on the root folder that limits the checkout depth to immediate (or empty) for a folder anywhere in the tree matching the list. By setting as a property, then a new checkout will inherit this property and limit the checkout depth for the named folders as required. Users can then checkout particular tag versions as normal if they require past versions. IMHO this will make the behavior of tags more like what the SVN manual says is just a "user friendly name for a revision". You wouldn't want to check out all revisions on the trunk, so why check out all revisions for tags by default? This would be a really cool improvement, as I see the problem has been mentioned many times on this group.
Re: Feature request: inhibit checkout of tags/branches
May have given the wrong impression here - its not access control but just limiting the depth of checkout to folders matching the list. On Thursday, 29 March 2012 12:49:57 UTC+1, Nico Kadel-Garcia wrote: > > On Thu, Mar 29, 2012 at 7:19 AM, Paul Coulson wrote: > >> I have a legacy repo structure that has many projects with their own tags >> and branches folders. >> >> Users check out the whole structure as there are common lib references >> etc, but they don't need to see the full contents >> of tags or branches folders, which can be massive. >> >> I would like a property svn:inhibit (similar to svn:ignore) set on the >> root folder >> that limits the checkout depth for a folder anywhere in the tree that >> matches the inhibit list. >> > > Woof. From the view of a sophisticated user, I don't think it's > feasible. Access control is built into daemons, mod_dav_svn, svnserver, and > file:/// access from the subversion client. Weaving in the ability to > parse the repository characteristics and restrict access on that basis is > asking for a signigifcant rewrite of the system, and sounds like a really, > really, destabilizing idea. It certainly wouldn't backport to older > Subversion server software. > > You can do some access control with Apache configurations or access.conf, > but neither of those will restrict file:/// access. I suggest you pick an > access method to allow, block all others, and rely on the existing > structures to do that kind of control on the server side. >
Sparse Checkout With Externals (1.7.6)
Specifiyinfg 'immediates' or 'files' does not checkout the externals for a folder with this property set. If you then do a checkout with 'infinity' you get the libs, but subsequent updates delete the lib again!. I can't seem to stop this behavior now as no matter what I do the lib always gets deleted. So: a) how do I do sparse checkout on a folder with externals b) how do I now get my libs to stay when I do an update?
mod_DontDoThat
I need to install this functionality for Apache, but I don’t have apxs and can't find a 64 bit version. Seems like I would also need Perl. Does anyone know where to obtain apxs for 64 bit Windows? Alternatively is there a Windows 64 pre-compiled version of mod_dontdothat?
Re: Sparse Checkout With Externals (1.7.6)
I found out that I need to use --set-depth to make the depth stick, so solved this one. Just setting --depth is ignored on the next update. On Apr 19, 2:50 pm, Johan Corveleyn wrote: > On Thu, Apr 19, 2012 at 2:42 PM, coolie wrote: > > Specifiyinfg 'immediates' or 'files' does not checkout the externals > > for a folder with this property set. > > Yes, this is a known > issue:http://subversion.tigris.org/issues/show_bug.cgi?id=3311(externals > are not created unless depth=infinity) > > > If you then do a checkout with 'infinity' you get the libs, but > > subsequent updates delete the lib again!. I can't seem to stop this > > behavior now as no matter what I do the lib always gets deleted. > > I don't understand this bit. Can you describe an example, preferably > with a set of command line commands, starting from an empty > repository, and demonstrating what you mean? > > -- > Johan
tags folder access denied
I seem to have lost the tags folder in the repository. I tried to create a new tag and maybe there was some interruption to the server or something, but now the whole tags folder is gone! If I try to re-create in repo-browser or add from the disk I get access denied. Is there something I can do on the server to either restore my tags or remove whatever is stopping me from re-creating it? I can create a folder of a different name but I can't rename it to tags. I performed verify and that came up with no problems. There is nothing specific in the Apache access file.
Re: tags folder access denied
I found a stray *= in the access folder - dont know how that got there doh! On Apr 19, 4:43 pm, Thorsten Schöning wrote: > Guten Tag coolie, > am Donnerstag, 19. April 2012 um 17:33 schrieben Sie: > > > Is there something I can do on the server to either restore my tags or > > remove whatever is stopping me from re-creating it? > > First look in the log if the tags folder really was deleted, if so, > revert that revision. If it's not deleted in the log you should see it > in repo browser, so make sure you look at head in the correct and not > something/somewhere else. > > 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 Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
