On 26/2/03 21:22, "Stefano Mazzocchi" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
