RE: older versions of the subversion server
We just upgraded from 1.3 to 1.6.x. Fortunately, we also got new servers for the new version, so that helped up. We upgraded by installing SVN on the new servers, exporting our repositories from the old (current production) servers, and importing to the new servers. If you have that option, it worked very well for us as we were able to do a dry run of the complete upgrade process. No, when working with the enterprise’s software repository, you can’t be too cautious. When planning an “in place” upgrade, it would be good to start with your current version and work out any issues you find on the upgrade. On the bright side, we had virtually no issues on our upgrade – the major issue was trying to get all of our users to upgrade their clients. Regards, Tom From: Alin [mailto:alin.tomoi...@ttu.edu] Sent: Thursday, June 17, 2010 4:09 PM To: Ryan Schmidt Cc: users@subversion.apache.org Subject: Re: older versions of the subversion server That is a very good question. Our subversion server has not been updated in a while and it is still on version 1.4.2. I was looking into updating it to take advantage of the new merge tracking features (among others). Since we are using such an old version, I wanted to replicate our production environment on a test server (thus requiring version 1.4.2) and performing the upgrade there first. Do you think I am being overly cautious? What are the chances for a problem to occur in the upgrade process? Thank you, Alin -Original Message- From: Ryan Schmidt mailto:ryan%20schmidt%20%3csubversion-20...@ryandesign.com%3e>> To: Tomoiaga, Alin mailto:%22Tomoiaga,%20alin%22%20%3calin.tomoi...@ttu.edu%3e>> Cc: users@subversion.apache.org mailto:%22us...@subversion.apache.org%22%20%3cusers@subversion.apache.org%3e>> Subject: Re: older versions of the subversion server Date: Wed, 16 Jun 2010 16:13:32 -0500 On Jun 16, 2010, at 11:11, Alin wrote: > I am trying to install an older version of subversion (1.4.2) on two Linux > systems Ubuntu and Red Hat ( 2.6.31-20-generic Ubuntu and 2.6.18-164.el5 ) > and I am having a hard time locating the older version packages for > subversion. > I tried both the Ubuntu and Red Hat repositories and the subversion website. > Can you please tell me if these packages are still available for download? Certainly the source is still available from the Subversion project's web site. Not sure where you'd get older precompiled packages for various OSes. Note that Subversion 1.4.x and earlier are unsupported by now, and when 1.7.0 comes out, support for 1.5.x will be dropped. Why do you need to use such an old version?
RE: older versions of the subversion server
No problem. That was a good tip from Ryan on the start-commit hook. I wish I had know about it, although we did publicize to our users well in advance that they needed to upgrade and they could do it anytime before we did our server upgrade. I really only got one call from a user and he was and Eclipse user. Regards, Tom From: Alin [mailto:alin.tomoi...@ttu.edu] Sent: Thursday, June 17, 2010 4:29 PM To: Ryan Schmidt; Thomas Loy Cc: users@subversion.apache.org Subject: Re: older versions of the subversion server Ryan and Thomas, Thank you very much for your advice. -Original Message- From: Ryan Schmidt mailto:ryan%20schmidt%20%3csubversion-20...@ryandesign.com%3e>> To: Thomas Loy mailto:thomas%20loy%20%3cthomas@cbeyond.net%3e>> Cc: Tomoiaga, Alin mailto:%22Tomoiaga,%20alin%22%20%3calin.tomoi...@ttu.edu%3e>>, users@subversion.apache.org mailto:%22us...@subversion.apache.org%22%20%3cusers@subversion.apache.org%3e>> Subject: Re: older versions of the subversion server Date: Thu, 17 Jun 2010 15:24:56 -0500 On Jun 17, 2010, at 15:18, Thomas Loy wrote: > On the bright side, we had virtually no issues on our upgrade – the major > issue was trying to get all of our users to upgrade their clients. There is at least a way you can automate advising your users to upgrade to Subverison 1.5 or later if they have 1.4.x or earlier: the start-commit hook script. This hook script will be passed a list of client capabilities; if the client capabilities do not include mergeinfo, you know it's older than 1.5. You could at that point abort the commit and print an error message advising the user to upgrade their client. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html I don't know of a way to detect the client version beyond that, though. And unfortunately early versions of 1.5.x weren't totally satisfactory for merge tracking, so you really do want your clients to be the latest version.
RE: viewing svn logs?
On Windows, Tortoise SVN is my choice. Regards, Tom From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Sent: Friday, August 06, 2010 10:58 AM To: 'Tom Cruickshank'; users@subversion.apache.org Subject: RE: viewing svn logs? What about TortoiseSVN? Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 From: Tom Cruickshank [mailto:tcruic...@gmail.com] Sent: 06 August 2010 15:54 To: users@subversion.apache.org Subject: viewing svn logs? Hey Guys, Wondering if there is any software out there (open source or proprietary) which would allow someone to view SVN logs in a gui based environment? What do you folks typically use if you don't mind me asking? Tom
RE: Setting "tags" to read only ?
We use access control to keep tags read-only, although pre-commit hooks would work as well, access control was simpler and a bit more foolproof. Regards, Tom -Original Message- From: a.sk...@gmail.com [mailto:a.sk...@gmail.com] On Behalf Of Alexander Skwar Sent: Wednesday, September 29, 2010 11:11 AM To: Phil Pinkerton Cc: users@subversion.apache.org Subject: Re: Setting "tags" to read only ? Hi. 2010/9/29 Phil Pinkerton : > Is it possible to set these tags to read-only once ther are copied from the > trunk to the tags directory ? How about using access control http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html so that only a certain user or group has rw access to the tags directory, while all others have just read r access? Alexander -- ↯ Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/ ↯ ↯ Chat (Jabber/Google Talk) ↣ a.sk...@gmail.com , AIM: alexws77 ↯
RE: Windows over linux
Agreed, but another benefit of any Unix OS is the ability to use symbolic links. They aren't in Windows and they give some added stability to some things you may do such as link a specific version name to a more generic name you use in the build script. This makes maintenance long term a lot easier. I'm working on a bunch of scripts right now where we had a version specific taskdef jar that I'm now using a symlink to create a generic jar name -- so I won't have to edit all the taskdef jar names in the scripts again. Cheers, Tom Thomas Loy Sysops - Build Engineer Cbeyond 320 Interstate North Pkwy. Suite 300 Atlanta, GA 30339 (678) 370-2383 thomas@cbeyond.net -Original Message- From: Chris Albertson [mailto:albertson.ch...@gmail.com] Sent: Tuesday, January 25, 2011 11:56 AM To: Oliver Marshall Cc: users@subversion.apache.org Subject: Re: Windows over linux On Tue, Jan 25, 2011 at 12:43 AM, Oliver Marshall wrote: > Hi, > > > > As far as subversion is concerned, is there any reason to go for one OS over > another when setting up a new subversion server? Are any of the hooks or > features OS dependant? Choose the OS that is the best stabilty nd the best file system performance. That would be Solaris and ZFS. But more people know about Linux so that is what they recommend. But do think about the file system and how you will be able to continue running and not have to re-boot or power down if a drive fails. Lots of ways to handle that. Last I looked (a while back) Windows required a re-boot after almost any trivial change of settings. It would be good if you could add additional storage space or even swap out drive without a re-boot. ZFS is made just for that. Windows is not as nice for remote access. Again because you need to re-boot and of course the re-boot kills the remote link. -- = Chris Albertson Redondo Beach, California
RE: Build project in pre-commit
No, if your project takes more than a few seconds to compile, it WILL annoy committers. I have a pre-commit that validates a Change Request Number in their comment against a database. It is a quick query, but it takes about 15 seconds to do the connect, query, and then disconnect. My committers are annoyed by that short a time. Cheers, Tom -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Tuesday, April 05, 2011 6:37 PM To: San Martino Cc: users@subversion.apache.org Subject: Re: Build project in pre-commit On Apr 5, 2011, at 17:08, San Martino wrote: > we absolutely need to validate a project in the pre-commit trigger > with a build of the whole project being committed. > > Is this possible? Are there any tools allowing this? Yes, you could write a script to do this. There might be existing scripts to do this. However, if your project takes more than a few seconds to compile, this will likely annoy committers.
RE: For Siebel
Subversion does have lock mechanisms, but they are not enabled by default. Although Siebel has it's lock mechanisms for sifs, I believe they are binary and you will want to implement locking in Subversion for them as well. I sure wish I could get our Siebel teams to use SVN instead of exclusively depending on Siebel's lock mechanisms! Regards, Tom From: Geoff Hoffman [mailto:ghoff...@cardinalpath.com] Sent: Wednesday, June 15, 2011 7:05 PM To: users@subversion.apache.org Subject: Re: For Siebel On Wed, Jun 15, 2011 at 3:06 PM, Mudumbai, Venkat mailto:venkat.mudum...@mercer.com>> wrote: Hi, We are planning to user SUBVERSION & TortoiseSVN for our Siebel Tools as a source control tools. Siebel development using tools, as it is a a object based environment, where in we checkout and check in the several objects like applets,buscomps,picklist,links etc. okay... In my previous project we used VSS as the version control tools. In this when we check in a "sif" of the object checked in is created in the VSS Server. I don't know what a "sif" is but SVN will store text and/or binary files under version control without any problems. Siebel itself has a lock on the object created when an object is checkout. All we want is to know if the copy of the sif's whenever they are checked can be stored in Subversion, with details like who has checkedin, when it was cecked in. Yes, that is exactly what it does. Here's some sample log output, gotten via command line: svn log --verbose svn+ssh://path-to-server/svn/repos/sites/client r279 | fredjones | 2011-04-26 17:10:40 -0700 (Tue, 26 Apr 2011) | 1 line Changed paths: M /sites/client/www/.htaccess M /sites/client/www/application/frontend/controllers/main.php M /sites/client/www/application/frontend/views/footer.php M /sites/client/www/application/frontend/views/header.php A /sites/client/www/application/frontend/views/menu.php D /sites/client/www/application/frontend/views/promotions.php Changed the .htaccess file and made the template modular. With this, you can see on Apr 26, fredjones modified 4 files, added one, and deleted one Also want to know how many versions of an object can be stored. Limited only by hard drive space where your repo is stored. Siebel is not a typical programming language. There's no such thing as a typical programming language. My question is : Can we use this SUBVERSION as a version control tools for our siebel tools. Please let me know as soon as possible as we are planning to install this s/w and do the set up as soon as possible. I don't see why not. Regarding this part: > Siebel itself has a lock on the object created when an object is checkout. The only thing is if you need Subversion to *not let Developer B checkout file X if Developer A already has it checked out*... I'm not sure it will do that. SVNt, by default, does not prevent checkout by Developer B. It expects you to instead merge manually, and expects you (the svn repository administrator, lead developer, etc) will do that part. If both Developer B and A checkout file X and they both modify it, the person who checks in first, gets their code into the repo without issue. The second developer probably will get a commit failure, with a message that his working copy is not up to date. He then has to merge his changes into the version in the repository, which is newer than what he checked out (because it was modified by the other developer's commit). It's not terribly difficult to manage merged code, but it is not a check-in-check-out system it is a version control system. I hope that helps - good luck.
RE: Subversion limits?
This brings up a question for me. I have a couple of repos that are over 5 years old and reaching close to 400GB of storage. I'd like to "trim" the first couple of years of versions and store them to some sort of "archive" repo and keep the most recent versions in an "active" repo. I've been toying with export commands but haven't had any success. I would like to back us away from any possible limits. Cheers, Thomas From: kmra...@rockwellcollins.com [mailto:kmra...@rockwellcollins.com] Sent: Friday, September 28, 2012 10:52 AM To: CHAZAL Julien Cc: users@subversion.apache.org Subject: Re: Subversion limits? > I manage a Subversion server that has the following configuration : > - SVN 1.6.9 > - FSFS storage mode > - Apache + mod_dav + subversion modules > - Linux Suse Enterprise Edition 32-bit > > On this SVN server, there are around 1100 SVN repositories for > around 2000 users. I have small repositories and also very heavy > repositories (the heaviest weighs around 33 GB on my linux > filesystem). The sum of my repositories weighs around 1TB. > > Do you know if there is a size limitation for a SVN repository in Subversion? > Do you know if there is a number limitation for SVN repositories on > a Subversion server? Does-it really decrease performances on the > subversion server? This really depends upon the hardware and how the users are using the server. That said, the largest server I have has 1800 repositories serving around 6500 users. The largest repository is around 400GB with around 7TB of total storage. The largest single commit I have seen is around 53GB. The larger repositories get, the longer it may take to do maintenance activities such as verifying, filtering, dumping, and loading a repository. This is why I'd recommend staying away from large repositories and large commits, but they do work. Subversion seems to be I/O bound, even on a high-end SAN. 1.7 seems to definitely chew more CPU and memory though. But, I've also seen multiple 1GB NICs near saturation on the server too... Things that can kill performance: - Slow filesystem I/O - Poorly written hook scripts - Commits with large numbers of files (1M+) - Lots of files locked (hundred of thousands+) - Slow authentication servers You could easily run into issues depending upon the filesystem type and how you have organized the repositories. For example, one large partition *might* be less efficient. Kevin R.
RE: svnsync crashes on a huge commit
We've had similar problems with large files with our svnsync. It has always been a time out problem. If you are using httpd there is a time out value in httpd.conf that can be increased (I don't recall the exact parameter). We also use VIPs for our SVN servers and we had an issue with the VIP having a time out at 2 minutes. We had to increase that temporarily to accommodate some very large commits. Cheers, Thomas From: Anatoly Zapadinsky [mailto:zapadin...@gmail.com] Sent: Tuesday, July 09, 2013 1:48 PM To: Anatoly Zapadinsky; users@subversion.apache.org Subject: Re: svnsync crashes on a huge commit it's very unlikely to be a memory leak... svnsync worked for 20+ hours and synchronized 300 000+ revisions and downloaded 65+ Gb during the one sync session before it felt in this trap. now it stuck... and can't synchronize this revision after restart. The procedure is very slow, it took more than an hour to sync this particular revision with 56000 files in it. The cumulative files size in this revision is not very big, the size is less than 4gb. Before it crashes transaction folder grows to 46mb in size and txn-protorevs is 4Gb. Looks like it has already downloaded all the files and crashed after it. Looks like it is a problem in handling huge commit and not a memory leak, also may be the server terminated connection. On Tue, Jul 9, 2013 at 9:13 PM, Stefan Sperling mailto:s...@elego.de>> wrote: On Tue, Jul 09, 2013 at 03:30:44PM +0400, Anatoly Zapadinsky wrote: > svnsync failed to sync repository with a single commit containing 56000 > files. This commit handled perfectly by console svn and tortoise svn. We > can checkout this folder structure and so on. But when I tried to sync this > commit to the local mirror repository it fails. > 32 bit version of svnsync crashed with out of memory exception. > 64 bit version made a transaction folder containing 117000 files in it, > allocated like 3gb of memory and finally crashed with this diagnostic: > "svn: E235000: In file 'subversion/libsvn_ra_serf/util.c' line 1649: > internal malfunction". > May be this commit is not an example of the best practice but it crash only > svnsync all the other svn tools handle it perfectly. > What should I do? How to mirror this repository? Is it a bug or not? This problem sounds like a memory leak. I wonder if you're running into the same problem this user is seeing: http://svn.haxx.se/users/archive-2013-07/0128.shtml
RE: svnserve: Interacting in tunnel mode
Why not use SVN Notifier available at http://svnnotifier.tigris.org? Cheers, Tom Loy -Original Message- From: Piotr Sipika [mailto:psip...@cengen.com] Sent: Wednesday, January 13, 2010 2:54 PM To: users@subversion.apache.org Subject: svnserve: Interacting in tunnel mode Hi, I'm trying to write a notification application which would monitor specific repositories and pop-up a dialog when an update has been detected. I noticed that 'svn log svn+ssh://...' launches 'svnserve -t' via ssh and believe this to be the best way for me to proceed. I tried running 'svnserve -t' on the command line and entering sample 'client' responses (following the syntax described in subversion/libsvn_ra_svn/protocol) to see if that approach would work, but no responses were visible. What is the best way for me to interact with svnserve in tunnel mode? Any and all help and suggestions will be much appreciated. Thanks, Pete
RE: svn dump and load not preserving all files
Which OS? Some operating systems have file size limits of 4 GB or less. Cheers, Tom Loy -Original Message- From: Jeremy Conlin [mailto:jlcon...@gmail.com] Sent: Tuesday, January 19, 2010 3:03 PM To: users@subversion.apache.org Subject: svn dump and load not preserving all files I am migrating my repository to a new server. This requires that I dump the original and the create a new repository on the new server and use the svnadmin load command to import everything. I have been able to do this for a few of my repositories, but one in particular isn't working. The dump file for this repository is > 9 GB. The load command starts out, but never finishes. The size of my repository gets to 2.1 GB and then it seems to stop even though the svnadmin load command is still running. Eventually (> 24 hours) the command stops (finishes) but the size of my repository is only 2.1 GB when it should be around 9 GB. Also, not all of the files have been restored. Is there a limit in the size of a dump file that can be used? I would be surprised if that limit were around 9 GB. I'm sure there are repositories that are much larger than that. Any ideas on what could be wrong? Thanks, Jeremy
RE: svn dump and load not preserving all files
UNIX has actual physical limits to file size determined by the number of bytes a 32 bit file pointer can index, about 2.4 GB. for older file systems or runtimes. Depending on your system, you may or may not have large file support. Try man fopen64 if you have an older UNIX. Cheers, Tom Loy -Original Message- From: Jeremy Conlin [mailto:jlcon...@gmail.com] Sent: Tuesday, January 19, 2010 3:22 PM To: Thomas Loy Cc: users@subversion.apache.org Subject: Re: svn dump and load not preserving all files On Tue, Jan 19, 2010 at 1:05 PM, Thomas Loy wrote: > Which OS? Some operating systems have file size limits of 4 GB or less. > > Cheers, > > Tom Loy > The original OS was on a Mac, the new OS is some *nix server, probably Linux. I don't believe either of these have limitations as small as 4GB. Am I wrong? Thanks, Jeremy > > -Original Message- > From: Jeremy Conlin [mailto:jlcon...@gmail.com] > Sent: Tuesday, January 19, 2010 3:03 PM > To: users@subversion.apache.org > Subject: svn dump and load not preserving all files > > I am migrating my repository to a new server. This requires that I > dump the original and the create a new repository on the new server > and use the svnadmin load command to import everything. I have been > able to do this for a few of my repositories, but one in particular > isn't working. The dump file for this repository is > 9 GB. The load > command starts out, but never finishes. The size of my repository > gets to 2.1 GB and then it seems to stop even though the svnadmin load > command is still running. Eventually (> 24 hours) the command stops > (finishes) but the size of my repository is only 2.1 GB when it should > be around 9 GB. Also, not all of the files have been restored. > > Is there a limit in the size of a dump file that can be used? I would > be surprised if that limit were around 9 GB. I'm sure there are > repositories that are much larger than that. > > Any ideas on what could be wrong? > > Thanks, > Jeremy >
RE: Automated Merging
Although I can't speak for the poster, this looks to be commercial software. A look at the parent website shows another build product for $1995 per server. Could be a useful tool, but since it isn't open source I doubt we'll take a close look at it since Build Engineering is at the bottom of the money food chain. Cheers, Tom Loy -Original Message- From: Pat Farrell [mailto:pfarr...@pfarrell.com] Sent: Monday, February 22, 2010 4:57 PM Cc: users@subversion.apache.org Subject: Re: Automated Merging k...@timpanisoftware.com wrote: > look at it, please check out the web site http://www.mergemagician.com. > If you'd like to download it, shoot me an e-mail and I'll send you the > download link. The website has some critical information missing. Before I look futher: What license do you expect to use? Is this FOSS? or commercial? If you expect users/companies to pay for your product, this is close to SPAM. -- Pat Farrell http://www.pfarrell.com/
Slowness on checkouts after upgrade/migration
Greetings, We just upgraded from 1.3.1 to 1.6.9 (Woo hoo!) and put the new SVN on some brand new servers. At the same time, we also setup some basic disaster recovery using svnsync to mirror the commits from our primary SVN server to our backup SVN server. I expected some performance degradation on commits, but we are getting some extreme degradation on checkouts as well. One of our applications uses Ivy for dependency management and it has a lot of third-party jars, some very large. On our build server, a build that used to take 10 minutes is now taking 30 minutes. Most of the additional time appears to be in the Ivy update/checkout for the application, but time to update/checkout the application's source code is also taking increased time. Keep in mind that these are essentially "clean" builds with complete retrievals of the Ivy repository and the source code repository. Does anyone have any ideas why our checkouts are taking so much longer than they used to? Regards, Thomas Loy Software Build Engineer Cbeyond, Inc.
RE: SVN Error
That would be the first thing I would do. What is the current timeout? Are you trying to use http or https? Regards, Tom From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com] Sent: Wednesday, May 19, 2010 10:58 AM To: users@subversion.apache.org Subject: SVN Error Hello, I am getting an error like this. I am using SVN 1.6.11 and Apache 2.2.14 svn: REPORT of '/!svn/vcc/default': Could not read response body: connection was closed by server I tried SVN checkout using file:/// method and it did not have any issues. Will changing "Timeout" in Apache configuration will help here? Best, Hemant Unstoppable..
RE: SVN Error
Glad to hear it. We had similar problems using svnsync when performing the initial sync. We had a couple of historic commits of a lot of third-party libraries that were very large. We had to bump the timeout up to 600 sec. to get svnsync to complete the sync. Now that we are syncing happily along, we will probably turn it back down to 300. Regards, Tom From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com] Sent: Thursday, May 20, 2010 3:17 AM To: Thomas Loy; users@subversion.apache.org Subject: RE: SVN Error Hey - setting Timeout as 300 resolved the problem. Best, Hemant Unstoppable.. From: Wadhavankar, Hemant Sent: Thursday, May 20, 2010 10:27 AM To: 'Thomas Loy'; users@subversion.apache.org Subject: RE: SVN Error Thanks Tom. I am using http and not https. I noticed "Timeout 300" in conf/extra/httpd-default.conf - but it is not getting called (include) in httpd.conf. So I will play around with it. Best, Hemant Unstoppable...... From: Thomas Loy [mailto:thomas@cbeyond.net] Sent: Wednesday, May 19, 2010 8:50 PM To: Wadhavankar, Hemant; users@subversion.apache.org Subject: RE: SVN Error That would be the first thing I would do. What is the current timeout? Are you trying to use http or https? Regards, Tom From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com] Sent: Wednesday, May 19, 2010 10:58 AM To: users@subversion.apache.org Subject: SVN Error Hello, I am getting an error like this. I am using SVN 1.6.11 and Apache 2.2.14 svn: REPORT of '/!svn/vcc/default': Could not read response body: connection was closed by server I tried SVN checkout using file:/// method and it did not have any issues. Will changing "Timeout" in Apache configuration will help here? Best, Hemant Unstoppable..
RE: Automatic commission?
No. You must use the SVN rename. Regards, Tom -Original Message- From: Peng Yu [mailto:pengyu...@gmail.com] Sent: Monday, May 24, 2010 5:54 PM To: Daniel Becroft Cc: users Subject: Re: Automatic commission? On Mon, May 24, 2010 at 4:46 PM, Daniel Becroft wrote: > On Tue, May 25, 2010 at 7:40 AM, Peng Yu wrote: >> It seems that I have to specify which file or files to commit. This >> will be a problem if I always simultaneously edit tens of files before >> I can do a commission. Is there an automatic way to figure out which >> files should be commit and commit them? > > You can not specify anything, and it will commit all changes (e.g. svn > commit -m ). > > See the book for an example: > http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.commit If I rename the files locally without using svn command, then I commit without any arguments. Will the command 'commit' be able to figure about the file with new name is modified from the old file? -- Regards, Peng
RE: compact repository (many files)
I wish I had an answer for you. We have a similar situation. I manage a dozen production SVN Repos and some are getting quite large. One repo has over 35,000 revisions. Some of the original revisions from years ago I'd like to extract and archive and just maintain the archive with history for say the past two or three years. I know I can dump a revision range, but as I understand it, a delete really doesn't delete. I can always go back to the deleted revisions in the history and get them. I would love to have a "permanent delete" that would help me eliminate some of the detritus my repos have and would help reduce their size. Regards, Tom -Original Message- From: Paul Ebermann [mailto:paul-eberm...@gmx.de] Sent: Wednesday, May 26, 2010 11:53 AM To: users@subversion.apache.org Subject: compact repository (many files) Hello, I have here a personal Subversion repository hosted on my university account (for easy access from everywhere via SSH). (Its format is a 1.5 FSFS, from the information in the meta-files.) I'm now to revision 2529, which means the whole repository has 5098 files (most of them in db/revs and db/revprops), and which each new revision I get two more files. (The whole repository is about 45 MB big, but that's not the matter here.) The problem now is that I have a quota limitation of 3 files here (additionally to a size limit), and my svn repository fills now about 1/6 of this, steadily growing, forcing me to delete other files ... Is there any way to reduce the file number of the repository without throwing away information? As in, throw the changes in revisions 0 ... 999 together in one file (and this way even safe some space for better compression)? (I don't care for worse performance, as those old revisions are used only very seldom.) I found nothing about this by extensive googling so I assume such a function is not yet implemented. Is this really a new idea, or was it discussed before and rejected? Or is there a simple workaround? Paul
