You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/02/26 22:22:24 UTC
[proposal] Pruning up the CVS tree for real
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?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [proposal] Pruning up the CVS tree for real
Posted by Berin Loritsch <bl...@apache.org>.
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?
>
+10000
Re: [proposal] Pruning up the CVS tree for real
Posted by Vadim Gritsenko <va...@verizon.net>.
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?
Suppose you have moved the sources... From, say, main src/java tree to
the block... Is it possible to preserve the history of the original
source file while doing this pruning? I suppose it could be done by
moving some files...
+10 to impove "cvs update" time.
+1000 to preserve history (have a web and CVS accessible copy of CVS on
cocoondev.org or some CVS file moves)
Vadim
Re: [proposal] Pruning up the CVS tree for real
Posted by Steven Noels <st...@outerthought.org>.
Ovidiu Predescu wrote:
> Getting a copy should be as simple as logging on cvs.apache.org and
> taring up /home/cvs/xml-cocoon2/. Then install them on cocoondev.org in
> the CVS directory.
Returning late to this thread, have been doing some customer work and it
looks like there has been quite some flux in the past few days.
So tell me: is my proposed action still needed, and if so, still possible?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Pruning up the CVS tree for real
Posted by Ovidiu Predescu <ov...@apache.org>.
On Wednesday, Feb 26, 2003, at 13:38 US/Pacific, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> Now, is anybody against having me going into the CVS tree and prune
>> stuff for real? [I promise to make a backup copy first :)]
>
> In the spirit of http://history.cocoondev.org/ (and the discussion
> around it, where you were pretty serious about keeping history alive),
> I was wondering if I shouldn't grab the current CVS tree and store it,
> CVS-accessible, on cocoondev.org. Not sure about the logistics and how
> easy that will be, but it might be better than a backup on your
> harddrive. Just an idea, fire at will.
It would be really great Steven if you could do it!
From time to time I find the need to refer back to things I did in the
old schecoon directory, to lookup an idea I had, etc. Having it on the
Web is so much simple than unpacking an archive at home.
Getting a copy should be as simple as logging on cvs.apache.org and
taring up /home/cvs/xml-cocoon2/. Then install them on cocoondev.org in
the CVS directory.
Thanks a lot for doing it!
Regards,
Ovidiu
Re: [proposal] Pruning up the CVS tree for real
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> Now, is anybody against having me going into the CVS tree and prune
> stuff for real? [I promise to make a backup copy first :)]
In the spirit of http://history.cocoondev.org/ (and the discussion
around it, where you were pretty serious about keeping history alive), I
was wondering if I shouldn't grab the current CVS tree and store it,
CVS-accessible, on cocoondev.org. Not sure about the logistics and how
easy that will be, but it might be better than a backup on your
harddrive. Just an idea, fire at will.
Other than this remark: +1 of course.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [proposal] Pruning up the CVS tree for real
Posted by Tony Collen <tc...@neuagency.com>.
On Wed, 26 Feb 2003, Stefano Mazzocchi wrote:
> 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.
Nope, go for it... I wouldn't mind seeing all those empty directories go
away, too :)
Tony
Re: [proposal] Pruning up the CVS tree for real
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 27/02/2003 11.54:
...
> I say we cleanup the scratchpad, finish up the build system and see what
> happens before starting new modules. I don't want another
> xml-cocoon-apps born-dead module.
Yes, I agree. I was just taking the opportunity of your real-life CVS
adventures to explain my view for the last (finally ;-) time.
As I said, 'nuff said from my part. The more time passes, the more I
think most if not all the scratchpad will go into blocks, and make this
a moot point (till schecoon-like proposal 2 will come, and then we'll
tackle it at that point ).
I still feel uneasy about declaring blocks unstable in a property, it
simply doesn't work as far as user and developer perception is related.
But I'll stand behind anything that the cocoon community will decide to
do on this matter, of course.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] Pruning up the CVS tree for real
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Stefano Mazzocchi wrote, On 27/02/2003 2.11:
> ...
>
>> Yes, CVS branches are evil. I'm starting to realize that.
>
>
> Ok, so you're starting to understand something about the use of
> cocoon-sandbox?
I still consider a separate module for alpha stuff a cimitery-wannabe.
>> Yes, we'll seriously think about moving to subversion when the tools
>> come.
>
>
> And when we'll move to it, I'd like to nuke the sandbox. We can use
> "branches" (see the SVN docs to see why I used the "") for alpha code.
> Now me thinks it's impractical. (we can also make it stating that it
> *will* be nuked upon passing to SVN). IMHO this holds true also for
> alpha blocks. I mean *really* alpha ones, not ones that are now marked
> unstable but are really in beta.
I say we cleanup the scratchpad, finish up the build system and see what
happens before starting new modules. I don't want another
xml-cocoon-apps born-dead module.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [proposal] Pruning up the CVS tree for real
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 27/02/2003 2.11:
...
> Yes, CVS branches are evil. I'm starting to realize that.
Ok, so you're starting to understand something about the use of
cocoon-sandbox?
> Yes, we'll seriously think about moving to subversion when the tools come.
And when we'll move to it, I'd like to nuke the sandbox. We can use
"branches" (see the SVN docs to see why I used the "") for alpha code.
Now me thinks it's impractical. (we can also make it stating that it
*will* be nuked upon passing to SVN). IMHO this holds true also for
alpha blocks. I mean *really* alpha ones, not ones that are now marked
unstable but are really in beta.
Hope this clarifies, 'nuff said from my part :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] Pruning up the CVS tree for real
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> Pier Fumagalli wrote:
>
>> On 27/2/03 1:11, "Stefano Mazzocchi" <st...@apache.org> wrote:
>>
>>
>>
>>> Pier Fumagalli wrote:
>>>
>>>
>>>> - 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...
>>
>
> I like your naming scheme, hope it sticks for a while. Extra ".x" does
> not really adds much value anyway.
No problem for me with the current naming schema.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [proposal] Pruning up the CVS tree for real
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 2:55, "Vadim Gritsenko" <va...@verizon.net> wrote:
> I like your naming scheme, hope it sticks for a while. Extra ".x" does
> not really adds much value anyway.
That's what I thought at the beginning! :-)
Anyhow, it's done now, all repositories have been moved and/or renamed...
Let's hope I just didn't break anything! :-)
Pier
Re: [proposal] Pruning up the CVS tree for real
Posted by Vadim Gritsenko <va...@verizon.net>.
Pier Fumagalli wrote:
>On 27/2/03 1:11, "Stefano Mazzocchi" <st...@apache.org> wrote:
>
>
>
>>Pier Fumagalli wrote:
>>
>>
>>>- 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...
>
I like your naming scheme, hope it sticks for a while. Extra ".x" does
not really adds much value anyway.
Vadim
Re: [proposal] Pruning up the CVS tree for real
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Pier Fumagalli wrote, On 27/02/2003 3.47:
>>>- 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...
blast it :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [proposal] Pruning up the CVS tree for real
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 1:11, "Stefano Mazzocchi" <st...@apache.org> wrote:
> Pier Fumagalli wrote:
>> On 26/2/03 21:22, "Stefano Mazzocchi" <st...@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.
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
awake!)
>> 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 <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.
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
manager)...
>> 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! :-)
Pier
Re: [proposal] Pruning up the CVS tree for real
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> On 26/2/03 21:22, "Stefano Mazzocchi" <st...@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 <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [proposal] Pruning up the CVS tree for real
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Berin Loritsch" <bl...@apache.org> wrote:
> Pier Fumagalli wrote:
>>
>> And no issues in UNIX AFAICS... We (VNU) have already planned the adoption
>> of SVN as our backend repository for a number of reasons (the primary one
>> being that we will use it as our distributed filesystem, having our web
>> applications deployed from a URL like http://svn.vnunet.com/app/live )...
>
> I assumed it was written primarily on UNIX--much like CVS originally
> was. That would explain the client/server reliability in those
> environments.
Actually, I believe that it's written also by an extended and reshaped set
of the original CVS authors...
>> But as for you, for us the client is _damn_ important... And we need not
>> only to think about UNIX (server side), but with windows (JSPs amd XML
>> writers) and with MacOS/9 and X (all our graphics production team)...
>
> Yep. To be honest I would not be happy if the server was on a Windows
> box--but that's just me. Windows is OK for the client (I am forced to
> use it for that), but it sucks for a server IMNSHO.
>
> Honestly, the primary concern for me is the svn CLI binary. All I want
> to do is use that. I don't use WinCVS, and most of the time do my
> checkouts/updates manually using CygWin (I love that tool--it lets me
> pretend I am on Unix while being forced to use Windows).
Yes, but I can't tell my graphics designers to use "svn ci" to do the whole
thing... They need something easier than that! :-)
>> We're testing hard on the baby, it's not quite there yet, but looks so
>> promising to us that we're investing quite a good amount of time on it..
>
> That's good news. I know XP gave the Mozilla project some fits (and for
> some reason I seemed to be the only experiencing those problems), but
> they seemed to have worked them out now. I am looking forward to when
> it is finished. I think the concept rocks.
SVN is based on APR, so if you're having troubles w/ it on XP, also Apache
2.0 will... Those issues will be sorted out pretty soon, I believe, if they
haven't already been addressed and fixed in the repositories...
> I do have one question though. In Cocoon CVS, and Avalon CVS, and many
> project's CVS, the source code has a "magick string" that automatically
> gets updated by CVS with the current revision and date that the file
> was last checked in. Will SVN have a replacement for that? Or will
> it support that feature from CVS? I imagine it would be a little more
> daunting as any checkin would update the $revision: 1.5.1.2$ string
> in every file because there is only one number for all the files. That
> would force all files to be updated everytime something is checked in.
Of course it does! :-) And you can even "extend" the set of properties you
want to attach to a file... Some properties (like "revision") are built in
and dealt with automatically (incrementing version number on each checkin).
Other properties can be custom and you can basically attach anything to them
(look at the DAV/DeltaV specs, I didn't follow closely this part in
particular, I just know that it can be done).
> Anyway, it isn't that important--but important enough to let people
> know about it.
Nono... "$revision" is important, IMVHO... And SVN supports it...
Pier
Re: [proposal] Pruning up the CVS tree for real
Posted by Berin Loritsch <bl...@apache.org>.
Pier Fumagalli wrote:
>
> And no issues in UNIX AFAICS... We (VNU) have already planned the adoption
> of SVN as our backend repository for a number of reasons (the primary one
> being that we will use it as our distributed filesystem, having our web
> applications deployed from a URL like http://svn.vnunet.com/app/live )...
I assumed it was written primarily on UNIX--much like CVS originally
was. That would explain the client/server reliability in those
environments.
> But as for you, for us the client is _damn_ important... And we need not
> only to think about UNIX (server side), but with windows (JSPs amd XML
> writers) and with MacOS/9 and X (all our graphics production team)...
Yep. To be honest I would not be happy if the server was on a Windows
box--but that's just me. Windows is OK for the client (I am forced to
use it for that), but it sucks for a server IMNSHO.
Honestly, the primary concern for me is the svn CLI binary. All I want
to do is use that. I don't use WinCVS, and most of the time do my
checkouts/updates manually using CygWin (I love that tool--it lets me
pretend I am on Unix while being forced to use Windows).
> We're testing hard on the baby, it's not quite there yet, but looks so
> promising to us that we're investing quite a good amount of time on it..
That's good news. I know XP gave the Mozilla project some fits (and for
some reason I seemed to be the only experiencing those problems), but
they seemed to have worked them out now. I am looking forward to when
it is finished. I think the concept rocks.
I do have one question though. In Cocoon CVS, and Avalon CVS, and many
project's CVS, the source code has a "magick string" that automatically
gets updated by CVS with the current revision and date that the file
was last checked in. Will SVN have a replacement for that? Or will
it support that feature from CVS? I imagine it would be a little more
daunting as any checkin would update the $revision: 1.5.1.2$ string
in every file because there is only one number for all the files. That
would force all files to be updated everytime something is checked in.
Anyway, it isn't that important--but important enough to let people
know about it.
Re: [proposal] Pruning up the CVS tree for real
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
I am happy to report that the new repository (cocoon-2.1) checks out,
builds and runs fine on MacOSX 10.2.4 + JVM 1.4.1.
The problems reported yesterday with Jetty under JVM 1.3.1 and the
'mail' and 'asciiart' blocks still exist, along with the strange
character encoding problem.
Thanks for all the great work!
regards Jeremy
Re: [proposal] Pruning up the CVS tree for real
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 13:06, "Berin Loritsch" <bl...@apache.org> wrote:
>> 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).
>
> I am not afraid of the command line, but there were issues with the
> release of the Windows client the last time I messed with it. When run
> on XP, it would fail miserably (core dump or something, can't quite
> remember). The information on the server was OK, but sometimes I had to
> make a commit more than once.
>
> I would like to see SubVersion improve a bit before making everyone
> switch. The client reliability issue is what has me gun shy about it.
> (No issues with the server that I can tell).
And no issues in UNIX AFAICS... We (VNU) have already planned the adoption
of SVN as our backend repository for a number of reasons (the primary one
being that we will use it as our distributed filesystem, having our web
applications deployed from a URL like http://svn.vnunet.com/app/live )...
Basically, no more checkouts, no more scripts, you apply the change to the
repository, and then it will go live straight away...
But as for you, for us the client is _damn_ important... And we need not
only to think about UNIX (server side), but with windows (JSPs amd XML
writers) and with MacOS/9 and X (all our graphics production team)...
We're testing hard on the baby, it's not quite there yet, but looks so
promising to us that we're investing quite a good amount of time on it..
Pier
Re: [proposal] Pruning up the CVS tree for real
Posted by Berin Loritsch <bl...@apache.org>.
Pier Fumagalli wrote:
> On 26/2/03 21:22, "Stefano Mazzocchi" <st...@apache.org> wrote:
>
> 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.
Maybe so, but what about getting rid of JARs for real? Esp. ones that
we may have found were incompatible with distributing them at apache?
> 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.
What about storing a log dump somewhere?
I mean, there comes a time where history is no longer useful. Then
again, according to murphy's law as soon as you get rid of something
you will then need it.
>
> 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).
I am not afraid of the command line, but there were issues with the
release of the Windows client the last time I messed with it. When run
on XP, it would fail miserably (core dump or something, can't quite
remember). The information on the server was OK, but sometimes I had to
make a commit more than once.
I would like to see SubVersion improve a bit before making everyone
switch. The client reliability issue is what has me gun shy about it.
(No issues with the server that I can tell).
Re: [proposal] Pruning up the CVS tree for real
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 26/2/03 21:22, "Stefano Mazzocchi" <st...@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