2011/9/28 Trevor Schaffer <TrevorSchaffer_at_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.levy_at_gmail.com]
> Sent: Wednesday, September 28, 2011 9:16 AM
> To: Trevor Schaffer
> Cc: Stefan Sperling; users_at_subversion.apache.org
> Subject: Re: revs files growing over time, relatively
>
> On Wed, Sep 28, 2011 at 11:01, Trevor Schaffer
> <TrevorSchaffer_at_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_at_oldrevnumber
Best regards,
Konstantin Kolinko
Received on 2011-09-28 18:11:45 CEST