Re: sparse working directories and externals
On Fri, Jan 28, 2011 at 4:35 PM, Dave Andreas wrote: > I’ve encountered a few anomalies regarding the sparse workaareas and > externals. I can construct a sparse workarea using either a top down > approach or a bottoms up approach as shown in the following examples > > Top down: > > $ svn co –depth immediates modules > > A modules > A modules/module1 > A modules/module2 > $ svn update –set-depth immediates modules/* > A modules/module1/subdir1 > A modules/module1/subdir2 > A modules/module2/subdir1 > A modules/module2/subdir2 > > $svn update –set-depth infinity modules/*/subdir1 > > A modules/module1/subdir1/file1 > A modules/module2/subdir1/file3 > > > Bottoms up: > > $svn co modules > > A modules > A modules/module1 > A modules/module1/subdir1 > A modules/module1/subdir1/file1 > A modules/module2/subdir2 > A modules/module1/subdir2/file2 > A modules/module2 > A moduels/module2/subdir1 > A modules/module2/subdir1/file3 > A modules/module2/subdir2 > A modules/module2/subdir2/file4 > A modules/external1/subdir1 > A modules/external1/subdir1/file5 > A modules/external1/subdir2/ > A modules/external1/subdir2/file6 > > $svn update –set-depth empty modules/*/subdir2 > > D modules/module1/subdir2/file2 > D modules/module2/subdir2/file4 > D modules/external1/subdir2/file6 > > > If it weren’t for the external, the result is the same. Unfortunately the > initial checkout of an external appears to be an all or nothing scenario > requiring a depth of infinity. > > The disadvantage of a bottoms up approach is that I’m checking out > everything from the repository into the workarea and them pruning it back. > In my actual case, I’m dealing with 10’s of thousands of file and this > process can take nearly 3 hours. > > The ideal solution would be a top down approach that handled externals > identically to modules from the local repository. > > Any suggestions? If I understand correctly, the problem is really at the start of your explanation, in that: > Top down: > > $ svn co –depth immediates modules > > A modules > A modules/module1 > A modules/module2 doesn't checkout modules/external1. If that would be the case, it would probably pan out the way you want, wouldn't it? I think this is issue #3311: http://subversion.tigris.org/issues/show_bug.cgi?id=3311 (externals are not created unless depth=infinity) I don't know an easy workaround. After your first step (checkout with depth=immediates), can you "manually" pull in the externals with eg. "svn update --set-depth=infinity external1"? In that case, maybe you could script something, using the output of "svn propget svn:externals" right after the "co --depth=immediates"? That would still pull in too much of the externals themselves, but maybe it makes it already a little more manageable ... Unfortunately, there is no way to limit the depth of pulling in the external itself, because of another issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3216 (externals with --depth) Cheers, -- Johan
Re: global SSL trust CA
On Fri, Jan 28, 2011 at 03:05:24PM +0100, Jehan PROCACCIA wrote: > Le 27/01/2011 20:04, Stefan Sperling a écrit : > >On Thu, Jan 27, 2011 at 06:52:02PM +0100, Jehan PROCACCIA wrote: > >>hello, > >> > >>since I configure my svn server in https , any time I do a co or ci > >>I get the server certificate presented and pompting me to accept it > >>temporarly or reject it. > >>To prevent that I set in ~/.subversion/servers > >>[global] > >>ssl-authority-files = /etc/pki/tls/certs/cachain.pem > >> > >>Now, is there a way to allow that CA file globally to all users on > >>the machine, because I don't want to ask each and every of my 200 > >>students to edit their ~/.subversion/servers . > >>isn't there a global configuration file for that ? > >Yes, there is: /etc/subversion/servers > > > >Stefan > thanks , copying my ~/.subversion/servers to > /etc/subversion/servers seems to do the job . > I run an rpm base distrib ... should'nt that file be there by > default ? or I missed to install a package ? > > # rpm -qa | grep subversion > subversion-javahl-1.6.13-1.fc13.i686 > subversion-1.6.13-1.fc13.i686 > subversion-libs-1.6.13-1.fc13.i686 > g > Wether that file exists by default is up to the packager. E.g. on OpenBSD it's present by default to configure svn to not store plaintext passwords by default. Stefan
Re: global SSL trust CA
On Sat, Jan 29, 2011 at 11:46 AM, Stefan Sperling wrote: > On Fri, Jan 28, 2011 at 03:05:24PM +0100, Jehan PROCACCIA wrote: >> Le 27/01/2011 20:04, Stefan Sperling a écrit : >> >On Thu, Jan 27, 2011 at 06:52:02PM +0100, Jehan PROCACCIA wrote: >> >>hello, >> >> >> >>since I configure my svn server in https , any time I do a co or ci >> >>I get the server certificate presented and pompting me to accept it >> >>temporarly or reject it. >> >>To prevent that I set in ~/.subversion/servers >> >>[global] >> >>ssl-authority-files = /etc/pki/tls/certs/cachain.pem >> >> >> >>Now, is there a way to allow that CA file globally to all users on >> >>the machine, because I don't want to ask each and every of my 200 >> >>students to edit their ~/.subversion/servers . >> >>isn't there a global configuration file for that ? >> >Yes, there is: /etc/subversion/servers >> > >> >Stefan >> thanks , copying my ~/.subversion/servers to >> /etc/subversion/servers seems to do the job . >> I run an rpm base distrib ... should'nt that file be there by >> default ? or I missed to install a package ? >> >> # rpm -qa | grep subversion >> subversion-javahl-1.6.13-1.fc13.i686 >> subversion-1.6.13-1.fc13.i686 >> subversion-libs-1.6.13-1.fc13.i686 >> g >> > > Wether that file exists by default is up to the packager. > E.g. on OpenBSD it's present by default to configure svn to not > store plaintext passwords by default. I'll suggest it for the next RPMforge update, I've been submitting Subversion there. Any idea on when 1.6.16 would happen? Or the plan to go to 1.17.0 next?
Re: externals behavior with tags
Thanks for the link. I knew the -rREV method was supported I just feel that doing that for every externally referenced file is a pain and one more thing to keep track of. Oh well. Is there a way to search for all instances of an externally ref file in the entire repo? I think a "where used" type function is what im looking for. -AG From: NN Ott ; To: amol gole ; Cc: ; Subject: Re: externals behavior with tags Sent: Wed, Jan 26, 2011 10:36:13 PM On Wed, Jan 26, 2011 at 5:02 PM, amol gole wrote: I am a tortise svn user. I recently started trying the svn:externals property to share files between projects. I got this feature to work and I am happy with it so far. > >My question is related to how tags should behave with such shared files. I use >tags as snapshots of my project in time. The tag is a copy of my trunk/branch >when I created it. However, if I am using shared files via the externals >property, these externally linked files will not be static - they will change >if >I do an update on my tag! This is definitely not the behavior I'm looking for. > > >Immediately I can think of 2 ways to "fix" this behavior of the tag not being >truly static: >1. In a tag, externally linked files loose their external link and are now >just >copies of the files. (yuck) >2. In a tag, the svn:externals property is changed slightly such that it >points >to the specific revision of the file when the tag was created. (using -rREV >url >filename format) > > >Is this really a problem or is there another fix available that I am unaware >of? > > > > Option 2 is supported, and in fact is the recommended method. See: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals
Re: externals behavior with tags
On Jan 29, 2011, at 20:01, amol gole wrote: > Thanks for the link. I knew the -rREV method was supported I just feel that > doing that for every externally referenced file is a pain and one more thing > to keep track of. Oh well. Don't use "-rREV URL" (an operative revision) in an externals definition. Do use "URL@REV" (a peg revision). I recommend you use a (peg) revision in every external you define. I don't consider this more work; I consider it an absolute necessity to unambiguously indicate what resource you're intending to obtain. > Is there a way to search for all instances of an externally ref file in the > entire repo? I think a "where used" type function is what im looking for. I don't think so.
Big, big safety problem in for subversion/trunk/kpackages/rpm/rhel-5/Makefile
I'm staring at the current Makefile for building RHEL packages, with
an eye towards getting in the RPMforge published tweaks into that
code. So far, so good, except 3 issues.
* RHEL 3 and RHEL 4 4 is nightmarish to build without updating Python
and a stack of other components. Unless someone's got a graceful way
to do it without major reconstruction of your local OS, they should be
discarded.
* The neon requirement in the .spec file for THEL 5 seems too
aggressive: it comes with neon-devel-0.25.5, and my preliminary tests
with subversion-1.7.0 base code work well with that.
* The sqlite requirement is normally handled for RHEL 5 by bundling
the "sqlite-amalgamation-3.t.13.tar.gz" recommended software. It's not
clear how to best bundle that into the Subversion repository itself
for RHEL 5 use, but it needs resolution for building on that OS.
* The %_sourcedir, %_builddir, etc. settings in .rpmmacros are all
lowercase. This does not match RedHat's standard of using BUILD,
SOURCES, RPMS, etc. for directory names for rpm configurations.
And biggest concern of all, because this *breaks* things.
* There's a build dependency that overwrites a user's
$HOME/.rpmmacros. This is hazardous in a development environment: it
will break the developer's other work. The easy way round that one is
to use "rpm --showrc" to extract the user's own settings for %_topdir,
and follow the RHEL defaults for RPMS in %{_topdir}/RPMS, sources in
%{_topdir}/SOURCES, etc. I'm looking into that. Then don't *touch* the
user's .rpmmacros, it's entirely unnecessary.
FW: Permanent deleting the deleted files.
Hi All, I am working on a repository in SVN. As this repository is quite old, its size has gone to 65GB. There were many files that was deleted. According to me SVN doesn't allow permanent delete. So all those deleted file would be stored in the back end as a revision. I can view the names of the deleted files from the log. So is there any way to permanently get rid of deleted files, as this will reduce my server space issue also. Is there any commands that I can run on the server to get the list of all deleted items and to permanently delete them. Any help will be appreciated. Regards, Rajnish K Singh
