[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Breaking up a monolothic repository

From: Trent W. Buck <trentbuck_at_gmail.com>
Date: Mon, 09 Sep 2013 15:27:59 +1000

Geoff Field <Geoff_Field_at_aapl.com.au> writes:

>> I get the impression that $company's projects mostly have a finite
>> lifespan (a couple of years),
>
> By "lifespan", what exactly do you mean? At my company, the
> individual projects might be in production within anywhere from 6
> months to 2 years after start of development, be manufactured for two
> to four years, then go into support mode for up to 7 years (or more).

That's probably a more accurate way of putting it.
But the bottom line is migration through attrition ought to work.

> It's entirely possible that the empty commit messages you reported
> were due to users not actually entering anything in the messages.
> Many of the commit messages I've seen (particularly from non-software
> people, but even from a few of those) are less informative than I'd
> like - a lot are totally empty.

Ah, sorry, I wasn't clear. Supposing the repo has two subdirs:

    projects/1_Muffins
    projects/2_Cakes

Then when I use svnsync to make a repo that only contains
projects/2_Cakes, I still have a bunch of commits that WERE making
changes to projects/1_Muffins -- so they have commit messages and
authors and times and suchlike metadata -- but they don't actually *do*
anything anymore, because they files they edited aren't in
projects/2_Cakes.

If there were only two projects, it wouldn't be too bad, but suppose 100
projects, with 1000 commits each. If I use svnsync, I end up with 100
repos, each of which has 99,000 useless commits.
Received on 2013-09-09 07:28:50 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.