cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [proposal] Pruning up the CVS tree for real
Date Thu, 27 Feb 2003 02:47:10 GMT
On 27/2/03 1:11, "Stefano Mazzocchi" <> wrote:

> Pier Fumagalli wrote:
>> On 26/2/03 21:22, "Stefano Mazzocchi" <> wrote:
>>> Running a CVS update takes a lot just for a few files. I believe this is
>>> due to the fact that xml-cocoon2 has reached 230Mb!!! of stuff.
>>> Now, is anybody against having me going into the CVS tree and prune
>>> stuff for real? [I promise to make a backup copy first :)]
>>> This will also solve the issue of seeing all those empty directories in
>>> ViewCVS that make our CVS repository look a mess from the web.
>>> Also, I plan to dive into the attic of all lib folders and blast all the
>>> previous versions of those files (we don't roll back libraries from CVS
>>> anyway).
>>> That will hopefully reduce the weight of our tree and improve 'cvs
>>> update' time (and reduce icarus load, which is not a bad thing at all)
>>> Comments?
>> Yes... A few. Pruning a tree by hand is a _very_ bad idea, IMVHO, because
>> it'll destroy all history of the project, and in our case, as we're using
>> branches, not only of the 2.1 tree, but of the 2.0 as well.
> Damn, I should have read this email before trying the pruning myself....
> I went from 230 Mb to 60Mb but find out later that I wiped out all the
> branches. :(
> Luckily enough, I made a backup :)
> So everything is back to normal now.

Good boy! :-) And when you do restore from a backup, make sure that you do a
chmod g+w so that I don't have to call you up at 2AM (cuz I know you're

>> But having managed CVS installs for the past 4 years, now, I kinda see the
>> point, the more you add stuff into history, the heavier the repository gets.
> Yes, CVS branches are evil. I'm starting to realize that.

Welcome to the world of haters of CVS... SVN _IS_ going to fix that...

>> Subversion _will_ solve this issue, that's for sure, so my suggestion would
>> be to move over onto that system, but there are IMHO, still issues with the
>> availability of non-command line clients. I would wait to start using it
>> until <> doesn't start working properly and it
>> gets more widely deployed (I'm watching that space because we want to use it
>> at VNU).
> Yes, we'll seriously think about moving to subversion when the tools come.

As I said, my work requires me to track it down, so, you'll be the second
one to know that all my tests are successful (first one is going to be my

>> My recommended plan of action to sort out this issue would be to hop on the
>> good foot of having our own PMC, and starting to move things around:
>> - Rename the "xml-cocoon" repository to "cocoon-1"
> I would say 'cocoon-1.x'

I moved the repository to be "cocoon-1"... The old one, though, is still
symlinked to the new name as people might have to do CVS diffs before being
able to switch over to the new repository

>> - Rename the "xml-cocoon2" repository to "cocoon-2"
> I would say 'cocoon-2-historical' or something like that

As above... But the name is "cocoon-2-historical"...

>> - Create a new repository called "cocoon-2.0" and copy over the cocoon-2_0_5
>>   branch of "xml-cocoon2" (clean checkout, and re-import)
> cocoon-2.0.x

I called this "cocoon-2.0", and it contains the latest copy of the
"cocoon_2_0_3" branch...

>> - Create a new repository called "cocoon-2.1" and copy over head from the
>>   main "xml-cocoon2" repository (clean checkout, and re-import)
> cocoon-2.1.x

Same as above, I called it cocoon-2.1...

Should I rename all the "new" repositories? I did it before seeing your
email, and I went ahead with my own naming scheme...

>> - Decide what to do with "xml-cocoon2-apps"
> blast it.

SUUUUUUURREEEEEEE??????????? Since the only one writing anything to that CVS
repo was Nicola Ken, I'd better ask him first before blasting something...

>> - Make sure that all cocoon committers are in the "cocoon" group and
>>   transfer ownership to that group of those newly created and renamed
>>   modules...
>> This is IMO the best way to go... I can make that happen in few minutes (max
>> 1/2 hour) when I'm granted access to the Cocoon group... I'll just need you
>> people not to do any commit in the old repo for a bit...
>> We don't loose history, and we get speed... What about it?
> +1, I learned it the hard way :/

You know? Whenever it comes to UNIX admin, you should really give your
friends up in London a call... :-) Me and Fede already did everything you
can possibly think of, and most of the times, had to revert back to DLT
tapes to get history back! :-)


View raw message