Les Mikesell writes:
> On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck wrote:
>> Ryan Schmidt writes:
>>
>>> As someone used to Subversion's usually sequential revision numbers,
>>> that bugs me aesthetically, but it works fine.
>>
>> I think
trentb...@gmail.com (Trent W. Buck) writes:
> So then I thought to chain the two approaches. This didn't work -- the
> empty revs were not removed. I guess svndumpfilter --drop-empty-revs
> is only smart enough to drop the revs that have just *become* empty?
>
>
Thorsten Schöning writes:
> Tell us about the size of your repo
> it's format version and primary data types versioned
(Sorry for not giving this info earlier, and shifting the goal posts --
I personally went rcs->arch->darcs->git and never really used svn, so
I'm feeling pretty noob attacking t
Ryan Schmidt writes:
> As someone used to Subversion's usually sequential revision numbers,
> that bugs me aesthetically, but it works fine.
I think that's the crux of it. Also part of the reason to split up the
repos is to make access control easier, and it looks bad if Alice (who
should have
Geoff Field 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 develo
Nico Kadel-Garcia writes:
> Lock the existing repo: Do clean exports, and imports, to new repositories
> with the new layout, with a README.md or other guideline to where the
> legacy repository exists. You lose the infinitely preserved history this
> way, but for most working software projects,
I have inherited a single monolithic repo for all the company's
projects. I want to migrate to one repo per project. (One-way,
one-time migration.)
Following the red-bean book[0], I first tried svnadmin, which was
really slow, and eventually crashed because some files were copied
into projects/13
