cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [proposal] Pruning up the CVS tree for real
Date Thu, 27 Feb 2003 01:11:32 GMT
Pier Fumagalli wrote:
> On 26/2/03 21:22, "Stefano Mazzocchi" <stefano@apache.org> 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.

> 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.

> 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 <http://tortoisesvn.tigris.org/> 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.

> 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'

> - Rename the "xml-cocoon2" repository to "cocoon-2"

I would say 'cocoon-2-historical' or something like that

> - 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
> 
> - 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

> - Decide what to do with "xml-cocoon2-apps"

blast it.

> - 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 :/

-- 
Stefano Mazzocchi                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



Mime
View raw message