You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Daniel Rall <dl...@collab.net> on 2004/11/15 03:12:28 UTC
[vote] Conversion of CVS modules to Subversion
What would y'all think about me converting our CVS modules to Subversion
<http://subversion.tigris.org/>? Subversion the next generation version
control system targeted by the ASF infrastructure team for apache.org.
It provides functionality very similar to CVS, but without so many of
its warts.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [vote] Conversion of CVS modules to Subversion
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>+1 As well,
>I think though that if we are going through the effort of moving things,
>lets not move JCS and keep it under the jakarta-turbine- envelope. Either
>leave it, or promote it out.
I've talked to the JCS guys (Aaron Smuts) multiple times but they haven't
created a proposal yet. So I'd simply leave them behind.
>Also, as far as other projects, I think only:
>jakarta-turbine-3
>jakarta-turbine-2
>jakarta-turbine-fulcrum
+1
>Henning, do we need to move jakarta-turbine-stratum? T2.4 doesn't use it,
>and I think I can remove it from T3 as well...
Turbine 2.3 uses it. We should just slap an "1.0" on it.
Regards
Henning
>Eric
>> -----Original Message-----
>> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
>> Sent: Monday, November 15, 2004 2:23 AM
>> To: turbine-dev@jakarta.apache.org
>> Subject: Re: [vote] Conversion of CVS modules to Subversion
>>
>>
>> Daniel Rall <dl...@collab.net> writes:
>>
>> >What would y'all think about me converting our CVS modules to Subversion
>> ><http://subversion.tigris.org/>? Subversion the next generation version
>> >control system targeted by the ASF infrastructure team for apache.org.
>> >It provides functionality very similar to CVS, but without so many of
>> >its warts.
>>
>> Basically +1
>>
>> Eric and I already discussed this a while ago. We wanted to discuss
>> some structure on how to do this before rushing into conversion.
>>
>> One of my concerns is e.g. as maven is our build tool, to make sure
>> that the report modules like maven-file-activity or
>> maven-developers-activity actually work with subversion as they do
>> with CVS.
>>
>>
>> Regards
>> Henning
>>
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>>
>> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
>> Linux, Java, perl, Solaris -- Consulting, Training, Development
>>
>> What is more important to you...
>> [ ] Product Security
>> or [ ] Quality of Sales and Marketing Support
>> -- actual question from a Microsoft customer survey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [vote] Conversion of CVS modules to Subversion
Posted by Eric Pugh <ep...@upstate.com>.
+1 from me as well.. If you care about tags, then you probably don't mind
doing a component by component basis... Most folks will go dreictly to the
head as well...
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Monday, November 29, 2004 3:51 PM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: [vote] Conversion of CVS modules to Subversion
>
>
> Niclas Hedhman <ni...@hedhman.org> writes:
>
> Looks good to me!
>
> I didn't think about the svn up issue; you're entirely correct here. I
> have the same problem with one of my projects (which does consist of a
> lot of diverse svn repos) and I worked around this by having a
> "checkout" directory where I tied all the trunks with svn:external.
>
> Regards
> Henning
>
>
>
> >On Monday 29 November 2004 22:19, Henning P. Schmiedehausen wrote:
>
> >> jakarta/
> >> fulcrum/
> >> component1/
> >> branches/
> >> tags/
> >> trunk/
> >> component2/
> >> branches/
> >> tags/
> >> trunk/
> >> component3/
> >> branches/
> >> tags/
> >> trunk/
>
> >I have previously tried this with a component oriented
> repository, and I would
> >like to recommend against it for one single reason;
> >When I (I assume others do the same) do updates I go to the
> highest possible
> >level and do an "svn up", which in the above scenario either
> would scan an
> >enormous amount of directories, and ending up being many times
> slower than
> >necessary.
>
> >May I suggest that you consider;
>
> > jakarta/
> > fulcrum/
> > trunk/
> > component1/
> > component2/
> > component3/
> > tags/
> > component1/
> > tag1
> > tag2
> > tag3
> > component2/
> > tag1
> > tag2
> > tag3
> > component3/
> > tag1
> > tag2
> > tag3
> > branches/
> > component1/
> > branch1
> > branch2
> > branch3
> > component2/
> > branch1
> > branch2
> > branch3
> > component3/
> > branch1
> > branch2
> > branch3
>
> >Or something similar where the trunk is kept easily updatable...
>
>
> >Cheers
> >Niclas
> >--
> > +------//-------------------+
> > / http://www.dpml.net /
> > / http://niclas.hedhman.org /
> >+------//-------------------+
>
>
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> What is more important to you...
> [ ] Product Security
> or [ ] Quality of Sales and Marketing Support
> -- actual question from a Microsoft customer survey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [vote] Conversion of CVS modules to Subversion
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Niclas Hedhman <ni...@hedhman.org> writes:
Looks good to me!
I didn't think about the svn up issue; you're entirely correct here. I
have the same problem with one of my projects (which does consist of a
lot of diverse svn repos) and I worked around this by having a
"checkout" directory where I tied all the trunks with svn:external.
Regards
Henning
>On Monday 29 November 2004 22:19, Henning P. Schmiedehausen wrote:
>> jakarta/
>> fulcrum/
>> component1/
>> branches/
>> tags/
>> trunk/
>> component2/
>> branches/
>> tags/
>> trunk/
>> component3/
>> branches/
>> tags/
>> trunk/
>I have previously tried this with a component oriented repository, and I would
>like to recommend against it for one single reason;
>When I (I assume others do the same) do updates I go to the highest possible
>level and do an "svn up", which in the above scenario either would scan an
>enormous amount of directories, and ending up being many times slower than
>necessary.
>May I suggest that you consider;
> jakarta/
> fulcrum/
> trunk/
> component1/
> component2/
> component3/
> tags/
> component1/
> tag1
> tag2
> tag3
> component2/
> tag1
> tag2
> tag3
> component3/
> tag1
> tag2
> tag3
> branches/
> component1/
> branch1
> branch2
> branch3
> component2/
> branch1
> branch2
> branch3
> component3/
> branch1
> branch2
> branch3
>Or something similar where the trunk is kept easily updatable...
>Cheers
>Niclas
>--
> +------//-------------------+
> / http://www.dpml.net /
> / http://niclas.hedhman.org /
>+------//-------------------+
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [vote] Conversion of CVS modules to Subversion
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 29 November 2004 22:19, Henning P. Schmiedehausen wrote:
> jakarta/
> fulcrum/
> component1/
> branches/
> tags/
> trunk/
> component2/
> branches/
> tags/
> trunk/
> component3/
> branches/
> tags/
> trunk/
I have previously tried this with a component oriented repository, and I would
like to recommend against it for one single reason;
When I (I assume others do the same) do updates I go to the highest possible
level and do an "svn up", which in the above scenario either would scan an
enormous amount of directories, and ending up being many times slower than
necessary.
May I suggest that you consider;
jakarta/
fulcrum/
trunk/
component1/
component2/
component3/
tags/
component1/
tag1
tag2
tag3
component2/
tag1
tag2
tag3
component3/
tag1
tag2
tag3
branches/
component1/
branch1
branch2
branch3
component2/
branch1
branch2
branch3
component3/
branch1
branch2
branch3
Or something similar where the trunk is kept easily updatable...
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [vote] Conversion of CVS modules to Subversion
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Rall <dl...@collab.net> writes:
>On Wed, 2004-11-17 at 07:17 +0000, Henning P. Schmiedehausen wrote:
>> Daniel Rall <dl...@collab.net> writes:
>>
>> >I'd be happy moving only those projects. Maven has had some degree of
>> >Subversion support for quite some time (available by wrapping the
>> >commandline binaries), but as to the specific functions referenced by
>> >Henning, I am not certain of the support. If it's missing, I'm willing
>> >to add it for Subversion.
>>
>> Cool. Then I'm all for it. What time frame do you propose?
>I'm ready any time. You and Eric give the word, as you two are
>producing the most code churn ATM.
Hi,
(back from ApacheCon, catching up with my mails...)
>Regarding layout, here's a strawman to nitpick which makes the
>assumption that neither the site module nor most of the other modules
>are in use:
>jakarta/
> fulcrum/
> branches/
> tags/
> trunk/
This is for Eric to say, personally I'd prefer
jakarta/
fulcrum/
component1/
branches/
tags/
trunk/
component2/
branches/
tags/
trunk/
component3/
branches/
tags/
trunk/
because else the tags directory will sooner or later filled with
literally hundreds of tags (foo-service-1.0, foo-service-1.1,
bar-service-1.0 and so on). I'd also like to decouple the various
components stronger which is easier (IMHO) if we don't have
trunk/
component1/
component2/
component3/
however, the reactor build might need this structure. Eric?
> jcs/
> branches/
> tags/
> trunk/
No call on that, however it seems that the JCS developers don't get
their act together on proposing for becoming a direct Jakarta
sub-project (come on folks! This is already an (almost done) deal. You
only need to send in your proposal!)
> turbine/
> branches/
> 2.2/ <-- branches from the jakarta-turbine-2 module
> 2.3/
> 3.0/ <-- the tip of the jakarta-turbine-3 module
I'm not happy with the 3.0 version tag. jakarta-turbine-3 is basically
a failed attempt at what Eric seems to get right with Turbine 2.4. I
don't want to block the innovation by having a "3.0" version that IMHO
will never get a release but will always be perceived as "newer" than
the Turbine 2.x release.
How about
turbine/
branches/
OLD/
turbine-2 <- Branches from jakarta-turbine-2
turbine-3 <- Branches from jakarta-turbine-3
2.3/
> tags/
> historical/ <-- the tip of the jakarta-turbine.old module
Where is this module? It is not visible at http://cvs.apache.org/viewcvs.cgi/
> trunk/ <-- the tip of the jakarta-turbine-2 module
-0. The problem with "trunk" is, that we don't have an uniform
"turbine" project. I definitely want to decouple META from the
HEAD/trunk and I have e.g. the ApacheFaces app as an example
application which I want to keep in the Turbine repo.
And also from Fulcrum, there are a few turbine-specific, but
core-decoupled components, that don't make sense outside of Turbine
(template service e.g.). I would be good to keep them in separate code bases.
I have a few Services, that build standalone vs. Turbine 2.3.x and I
have no intention to roll them into the turbine.jar. I'd like to put
them in their own tree and maintain them there.
Personally, I plan on
turbine/
branches/
2.3/
core/ <- Current TURBINE_2_3_BRANCH
services/
service1/
service2/
service3/
examples/
and I would really like to see
turbine/
trunk/
core/ <-- Current CVS HEAD
components/
turbine-specific-component1/
turbine-specific-component2/
examples/
example1/
example2/
meta/
>This layout assumes that Fulcrum and JCS will eventually fully decouple
>from Turbine and become its own full-fledged Jakarta project, a
>repository of useful Avalon services. "historical" could alternately be
>called "ancient".
+1.
>Fortunately, with Subversion, we can change this layout after importing
>if we run into an "Oops!".
>For your reference, here's the list of existing CVS modules:
>dlr@minotaur:cvs$ ls -d *turbine*
>jakarta-turbine-2/ jakarta-turbine-orgami/
>jakarta-turbine-3/ jakarta-turbine-site/
>jakarta-turbine-component/ jakarta-turbine-stratum/
>jakarta-turbine-flux/ jakarta-turbine-tdk/
>jakarta-turbine-fulcrum/ jakarta-turbine-tdk.old/
>jakarta-turbine-jcs/ jakarta-turbine-torque.old/
>jakarta-turbine-jyve/ jakarta-turbine.old/
There is a thread at
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=turbine-dev@jakarta.apache.org&msgId=1800768
where I summarized the various projects.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [vote] Conversion of CVS modules to Subversion
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 2004-11-17 at 07:17 +0000, Henning P. Schmiedehausen wrote:
> Daniel Rall <dl...@collab.net> writes:
>
> >I'd be happy moving only those projects. Maven has had some degree of
> >Subversion support for quite some time (available by wrapping the
> >commandline binaries), but as to the specific functions referenced by
> >Henning, I am not certain of the support. If it's missing, I'm willing
> >to add it for Subversion.
>
> Cool. Then I'm all for it. What time frame do you propose?
I'm ready any time. You and Eric give the word, as you two are
producing the most code churn ATM.
Regarding layout, here's a strawman to nitpick which makes the
assumption that neither the site module nor most of the other modules
are in use:
jakarta/
fulcrum/
branches/
tags/
trunk/
jcs/
branches/
tags/
trunk/
turbine/
branches/
2.2/ <-- branches from the jakarta-turbine-2 module
2.3/
3.0/ <-- the tip of the jakarta-turbine-3 module
tags/
historical/ <-- the tip of the jakarta-turbine.old module
trunk/ <-- the tip of the jakarta-turbine-2 module
This layout assumes that Fulcrum and JCS will eventually fully decouple
from Turbine and become its own full-fledged Jakarta project, a
repository of useful Avalon services. "historical" could alternately be
called "ancient".
Fortunately, with Subversion, we can change this layout after importing
if we run into an "Oops!".
For your reference, here's the list of existing CVS modules:
dlr@minotaur:cvs$ ls -d *turbine*
jakarta-turbine-2/ jakarta-turbine-orgami/
jakarta-turbine-3/ jakarta-turbine-site/
jakarta-turbine-component/ jakarta-turbine-stratum/
jakarta-turbine-flux/ jakarta-turbine-tdk/
jakarta-turbine-fulcrum/ jakarta-turbine-tdk.old/
jakarta-turbine-jcs/ jakarta-turbine-torque.old/
jakarta-turbine-jyve/ jakarta-turbine.old/
All modules would be marked read-only after the conversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [vote] Conversion of CVS modules to Subversion
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Rall <dl...@collab.net> writes:
>I'd be happy moving only those projects. Maven has had some degree of
>Subversion support for quite some time (available by wrapping the
>commandline binaries), but as to the specific functions referenced by
>Henning, I am not certain of the support. If it's missing, I'm willing
>to add it for Subversion.
Cool. Then I'm all for it. What time frame do you propose?
Regards
Henning
>On Mon, 2004-11-15 at 09:07 +0000, Eric Pugh wrote:
>> +1 As well,
>>
>> I think though that if we are going through the effort of moving things,
>> lets not move JCS and keep it under the jakarta-turbine- envelope. Either
>> leave it, or promote it out.
>>
>> Also, as far as other projects, I think only:
>> jakarta-turbine-3
>> jakarta-turbine-2
>> jakarta-turbine-fulcrum
>>
>> Henning, do we need to move jakarta-turbine-stratum? T2.4 doesn't use it,
>> and I think I can remove it from T3 as well...
>>
>> Eric
>>
>> > -----Original Message-----
>> > From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
>> > Sent: Monday, November 15, 2004 2:23 AM
>> > To: turbine-dev@jakarta.apache.org
>> > Subject: Re: [vote] Conversion of CVS modules to Subversion
>> >
>> >
>> > Daniel Rall <dl...@collab.net> writes:
>> >
>> > >What would y'all think about me converting our CVS modules to Subversion
>> > ><http://subversion.tigris.org/>? Subversion the next generation version
>> > >control system targeted by the ASF infrastructure team for apache.org.
>> > >It provides functionality very similar to CVS, but without so many of
>> > >its warts.
>> >
>> > Basically +1
>> >
>> > Eric and I already discussed this a while ago. We wanted to discuss
>> > some structure on how to do this before rushing into conversion.
>> >
>> > One of my concerns is e.g. as maven is our build tool, to make sure
>> > that the report modules like maven-file-activity or
>> > maven-developers-activity actually work with subversion as they do
>> > with CVS.
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [vote] Conversion of CVS modules to Subversion
Posted by Daniel Rall <dl...@collab.net>.
FYI, here's how I did the Velocity repo:
https://svn.apache.org/repos/asf/jakarta/
And here's an email I sent about it:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
dev@jakarta.apache.org&msgNo=11305
On Mon, 2004-11-15 at 13:15 -0800, Daniel Rall wrote:
> I'd be happy moving only those projects. Maven has had some degree of
> Subversion support for quite some time (available by wrapping the
> commandline binaries), but as to the specific functions referenced by
> Henning, I am not certain of the support. If it's missing, I'm willing
> to add it for Subversion.
>
>
> On Mon, 2004-11-15 at 09:07 +0000, Eric Pugh wrote:
> > +1 As well,
> >
> > I think though that if we are going through the effort of moving things,
> > lets not move JCS and keep it under the jakarta-turbine- envelope. Either
> > leave it, or promote it out.
> >
> > Also, as far as other projects, I think only:
> > jakarta-turbine-3
> > jakarta-turbine-2
> > jakarta-turbine-fulcrum
> >
> > Henning, do we need to move jakarta-turbine-stratum? T2.4 doesn't use it,
> > and I think I can remove it from T3 as well...
> >
> > Eric
> >
> > > -----Original Message-----
> > > From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> > > Sent: Monday, November 15, 2004 2:23 AM
> > > To: turbine-dev@jakarta.apache.org
> > > Subject: Re: [vote] Conversion of CVS modules to Subversion
> > >
> > >
> > > Daniel Rall <dl...@collab.net> writes:
> > >
> > > >What would y'all think about me converting our CVS modules to Subversion
> > > ><http://subversion.tigris.org/>? Subversion the next generation version
> > > >control system targeted by the ASF infrastructure team for apache.org.
> > > >It provides functionality very similar to CVS, but without so many of
> > > >its warts.
> > >
> > > Basically +1
> > >
> > > Eric and I already discussed this a while ago. We wanted to discuss
> > > some structure on how to do this before rushing into conversion.
> > >
> > > One of my concerns is e.g. as maven is our build tool, to make sure
> > > that the report modules like maven-file-activity or
> > > maven-developers-activity actually work with subversion as they do
> > > with CVS.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [vote] Conversion of CVS modules to Subversion
Posted by Daniel Rall <dl...@collab.net>.
I'd be happy moving only those projects. Maven has had some degree of
Subversion support for quite some time (available by wrapping the
commandline binaries), but as to the specific functions referenced by
Henning, I am not certain of the support. If it's missing, I'm willing
to add it for Subversion.
On Mon, 2004-11-15 at 09:07 +0000, Eric Pugh wrote:
> +1 As well,
>
> I think though that if we are going through the effort of moving things,
> lets not move JCS and keep it under the jakarta-turbine- envelope. Either
> leave it, or promote it out.
>
> Also, as far as other projects, I think only:
> jakarta-turbine-3
> jakarta-turbine-2
> jakarta-turbine-fulcrum
>
> Henning, do we need to move jakarta-turbine-stratum? T2.4 doesn't use it,
> and I think I can remove it from T3 as well...
>
> Eric
>
> > -----Original Message-----
> > From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> > Sent: Monday, November 15, 2004 2:23 AM
> > To: turbine-dev@jakarta.apache.org
> > Subject: Re: [vote] Conversion of CVS modules to Subversion
> >
> >
> > Daniel Rall <dl...@collab.net> writes:
> >
> > >What would y'all think about me converting our CVS modules to Subversion
> > ><http://subversion.tigris.org/>? Subversion the next generation version
> > >control system targeted by the ASF infrastructure team for apache.org.
> > >It provides functionality very similar to CVS, but without so many of
> > >its warts.
> >
> > Basically +1
> >
> > Eric and I already discussed this a while ago. We wanted to discuss
> > some structure on how to do this before rushing into conversion.
> >
> > One of my concerns is e.g. as maven is our build tool, to make sure
> > that the report modules like maven-file-activity or
> > maven-developers-activity actually work with subversion as they do
> > with CVS.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [vote] Conversion of CVS modules to Subversion
Posted by Eric Pugh <ep...@upstate.com>.
+1 As well,
I think though that if we are going through the effort of moving things,
lets not move JCS and keep it under the jakarta-turbine- envelope. Either
leave it, or promote it out.
Also, as far as other projects, I think only:
jakarta-turbine-3
jakarta-turbine-2
jakarta-turbine-fulcrum
Henning, do we need to move jakarta-turbine-stratum? T2.4 doesn't use it,
and I think I can remove it from T3 as well...
Eric
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Monday, November 15, 2004 2:23 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: [vote] Conversion of CVS modules to Subversion
>
>
> Daniel Rall <dl...@collab.net> writes:
>
> >What would y'all think about me converting our CVS modules to Subversion
> ><http://subversion.tigris.org/>? Subversion the next generation version
> >control system targeted by the ASF infrastructure team for apache.org.
> >It provides functionality very similar to CVS, but without so many of
> >its warts.
>
> Basically +1
>
> Eric and I already discussed this a while ago. We wanted to discuss
> some structure on how to do this before rushing into conversion.
>
> One of my concerns is e.g. as maven is our build tool, to make sure
> that the report modules like maven-file-activity or
> maven-developers-activity actually work with subversion as they do
> with CVS.
>
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> What is more important to you...
> [ ] Product Security
> or [ ] Quality of Sales and Marketing Support
> -- actual question from a Microsoft customer survey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [vote] Conversion of CVS modules to Subversion
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Rall <dl...@collab.net> writes:
>What would y'all think about me converting our CVS modules to Subversion
><http://subversion.tigris.org/>? Subversion the next generation version
>control system targeted by the ASF infrastructure team for apache.org.
>It provides functionality very similar to CVS, but without so many of
>its warts.
Basically +1
Eric and I already discussed this a while ago. We wanted to discuss
some structure on how to do this before rushing into conversion.
One of my concerns is e.g. as maven is our build tool, to make sure
that the report modules like maven-file-activity or
maven-developers-activity actually work with subversion as they do
with CVS.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org