2011/9/28 Trevor Schaffer <trevorschaf...@smarttech.com>: > Yes, that basically will have to be our plan... going forward. Now to try to > deal with what we have right now. > > I am a bit puzzled why the commit requires any information about other > folders seemingly not associated in any way with this particular commit > though. I'm sure the database has it for its reasons, so I won't question > that too much. > > -----Original Message----- > From: Andy Levy [mailto:andy.l...@gmail.com] > Sent: Wednesday, September 28, 2011 9:16 AM > To: Trevor Schaffer > Cc: Stefan Sperling; users@subversion.apache.org > Subject: Re: revs files growing over time, relatively > > On Wed, Sep 28, 2011 at 11:01, Trevor Schaffer > <trevorschaf...@smarttech.com> wrote: >> We definitely use svn copy for revisions, but I think the issue is because >> our tags are too flat vs not flat enough. >> >> E.g. tags/builds/ is where we put all of our tags (all done with svn copy) >> And over time, this folder has over 7000 tags in it. So now, ever new tag >> we put into /tags/builds has a listing of every other tag from tags/builds >> in the revs/db/<rev> file. Now when you have 4 lines in each rev file for >> each entry in the tags folder, that's 28000 lines of text, which gives us >> the roughly 600KB of data. And you can see how this grows over time. So >> obviously, in hindsight... we need to lessen the tags significantly, but >> current processes in our company will not allow us to do that quickly, or >> easily. > > Would it be possible to clean up your tags directory, maybe on a > quarterly or annual basis? So instead of having a flat /tags/builds > "dumping ground", you have; > > /tags/builds/ > /tags/builds/2011Q1 > /tags/builds/2011Q2 > /tags/builds/2011Q3 > /tags/builds/2011Q4 > > Your tags go into /tags/builds as they do today, but then at the end > of each quarter, you move that quarter's builds into the corresponding > directory. >
Huh. Top-posing is bad. When you create a new tag "tags/FOO" it results of a new version of "tags" directory. Subversion is not able to compare two directories and store a "delta" between them. Instead it stores a new complete version of the "tags" directory. (I think that gives better performance when someone needs to read that directory). Thus, as you noted, 7000 tags become 600KB of data. I agree with Andy's proposal to shard tags directory into several sections, e.g. by date. Though it would be easier if those quaterly directories were outside of your "builds" directory. E.g.: /tags/builds/ /tags/builds-archive-2011-01/ In is easy to do "svn mv ^/tags/builds ^/tags/builds-archive-2011-01/" in one transaction. Then you follow it by "svn mkdir ^/tags/builds" Note: 1) svnmucc allows to perform both mv and mkdir in one commit 2) you can still access your old tags at the old place it you use peg revisions, /tags/builds/MYOLDTAG@oldrevnumber Best regards, Konstantin Kolinko
