Re: CVS->SVN Was: SVN of ECS

[Martin Cooper <mf...@gmail.com>]

On Sat, 25 Sep 2004 21:25:37 +0100, robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> On 24 Sep 2004, at 19:55, Henri Yandell wrote:
> 
> > Sounds good to me. ORO's the first to goto SVN then.
> 
> cool
> 
> > Noel (or any other local to Jakarta infra people), before I go ahead
> > and just make a request, is there a particular process you'd like us
> > to adhere to?
> 
> given jakarta's large and diverse, i'd say that we need some kind of
> documented procedure. otherwise, it could get really messy and create a
> lot of trouble for infrastructure.

There is this to start with:

http://www.apache.org/dev/cvs2svn.html

--
Martin Cooper


> 
> - robert
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: CVS->SVN Was: SVN of ECS

[Henri Yandell <ba...@generationjava.com>]

On Sat, 25 Sep 2004, Martin Cooper wrote:

> There is this to start with:
>
> http://www.apache.org/dev/cvs2svn.html

Cool, just what I was hoping for.

Seems that the only major thing we have to do is plan step 2:

"Decide how you want your repository converted. Read the cvs2svn manual
  for the different ways in which you can convert your CVS repository. You
  should then come up with a set of conversion instructions like this. "

We need to make sure we have this decided for all of Jakarta when we begin 
our move, and not just a single sub-project, else it could bite us in the 
long term.

I've used Subversion a fair bit, and set a server up, but am a mile away 
from being an expert. Still, I figure I can kick us off with a suggestion 
and everyone can lambast my stupidity/arrogance.
Once/if we find a decision, we should also try to get some expert opinions 
on it. Either from Infra, or Fitzpatrick or someone.

By the way, the current svn structure can be seen at:

http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN

-----
It's a given that we want to keep our cvs history, though bringing all the 
tags over may be hard/a-challenge. Still, that's what svn experts/infra 
are for.

It looks like it's a given that we'll have a jakarta/ top level directory. 
All other TLPs are organized this way and I doubt we could do differently.

So, with that in mind, there seem two directions, though my 2nd suggestion 
could have various adaptations:

1
-
Should we just decide that it will be jakarta/<subproject> and let each 
subproject do what it wants underneath? Easier, but less organized.

2
-
Going with the example of trunk/tags/branches/site, I'd like to suggest 
using releases/ rather than tags/. It seems closer to what we mean. Tags 
does seem more common though, so just a suggestion.

Lots of site/ directories will encourage everyone to deploy their sites 
through version control without enforcing how they get it in there. We can 
then have a cronned svn-export or svn-update on the server-side.

-----

jakarta/
   tomcat/
     trunk/
     releases/
     branches/
     site/
   ecs/
     trunk/
     releases/
     branches/
     site/
   commons/
     lang/
       trunk/
       releases/
       branches/
       site/
     collections/
       trunk/
       releases/
       branches/
       site/
     site/
   site/

-----

So, that's the suggestion. Opinions?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org