cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [proposal] Pruning up the CVS tree for real
Date Wed, 26 Feb 2003 22:54:35 GMT
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.

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.

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

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"

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

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

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

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

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

    Pier




Mime
View raw message