incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: [long but important] importing cvs history
Date Fri, 23 Dec 2005 18:39:16 GMT
I may have to agree with Jim on this.  If we have the history in
Codehaus, does it make sense on this side of the fence?  The reason I
say this is we will have references to LGPL code in history and would
this cause a problem bringing that over?  I guess in the end it doesn't
really matter if we have all history over here, but I am wondering if
there will be a rule violation in doing it?

James Goodwill wrote:
> Jules, I don't disagree about the importance of the history. I just
> thought it would be a bit easier to keep the history safely on codehaus.
> 
> 
> On Dec 23, 2005, at 11:28 AM, Jules Gosnell wrote:
> 
>> James Goodwill wrote:
>>
>>> I think we should leave all history to date on codehaus.
>>
>> why ?
>>
>> I consider the history of my code a very important development
>> resource. You will have to come up with a really good reason to get me
>> to leave it behind.
>>
>> Jules
>>
>>>
>>> Jim
>>>
>>>
>>> On Dec 23, 2005, at 9:43 AM, Geir Magnusson Jr wrote:
>>>
>>>>
>>>> On Dec 23, 2005, at 9:45 AM, Bill Dudney wrote:
>>>>
>>>>>
>>>>> On Dec 23, 2005, at 7:16 AM, Geir Magnusson Jr. wrote:
>>>>>
>>>>>>
>>>>>> On Dec 23, 2005, at 8:31 AM, Bill Dudney wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> We need to decide what we are going to do about getting the 
>>>>>>> codehaus CVS history into our apache SVN repo.
>>>>>>>
>>>>>>> I would like this decided soon because I have several changes

>>>>>>> related to getting to the next ActiveCluster version that I'd

>>>>>>> really like to get checked in.
>>>>>>>
>>>>>>> I see at least 2 options;
>>>>>>>
>>>>>>> 1) Leave the history on codehaus in a codehaus SVN repo (Bruce

>>>>>>> can convert existing CVS to SVN fairly quickly from what I 
>>>>>>> understand) - conversion to SVN has to be done anyway because
we 
>>>>>>> have ongoing development of the GPL/LGPL bits (JBoss & JGroups)

>>>>>>> to contend with. Initally this would look something like this

>>>>>>> (summarized from a discussion started Dec 17th);
>>>>>>>
>>>>>>> Bruce:
>>>>>>> CVS Head (including history if possible) -> SVN trunk @ codehaus

>>>>>>> - branches and tags in CVS can be ignored unless there is some

>>>>>>> branch/tag that was abandoned that Jules thinks we might want
to 
>>>>>>> go after again. The branches and tags don't need to be left out,

>>>>>>> just do which ever is easier.
>>>>>>>
>>>>>>> Bill:
>>>>>>> a) Tag the code as 'left for apache' or something like that.
>>>>>>> b) From trunk remove all the code that was moved to apache and

>>>>>>> rearrange and clean up pom's - this will leave behind only the

>>>>>>> jboss & jgroups code
>>>>>>>
>>>>>>> Something like this - your feedback is appreciated;
>>>>>>
>>>>>>
>>>>>> How about just get the CVS tree and we import that?  We have the

>>>>>> ability here at the ASF....
>>>>>>
>>>>>
>>>>> Not sure I follow, tar the CVS tree on codehaus, copy it over to 
>>>>> ASF then import from there?
>>>>>
>>>>
>>>> Yes
>>>>
>>>>> That would be fine and is close to what I'm proposing below. 
>>>>> However it does have the complexities that there are LGPL/GPL 
>>>>> dependencies in the CVS tree that are not part of what is 
>>>>> currently in SVN on apache, we want to leave the LGPL/GPL related 
>>>>> code on codehaus (i.e. integration with JBoss & JGroups).
>>>>
>>>>
>>>> That's a good question.  I would assume we'd suck the whole thing 
>>>> in, and just chuck out that stuff.  or not suck those parts in in 
>>>> the first place, if possible.
>>>>
>>>>>
>>>>> Thanks again,
>>>>>
>>>>> -bd-
>>>>>
>>>>>> geir
>>>>>>
>>>>>>>
>>>>>>>     trunk/
>>>>>>>         jgroups
>>>>>>>         jboss
>>>>>>>
>>>>>>> Then from tags/left_for_apache we can get at the old code and

>>>>>>> all its history, going forward only jboss & jgroups related
code 
>>>>>>> will be developed @ codehaus.
>>>>>>>
>>>>>>> 2) Move the entire history of our code over to apache. From 
>>>>>>> discussion with Noel B. @ apachecon this is not standard 
>>>>>>> operating procedure but one of the emails we got from Geir made

>>>>>>> me think its no big deal (Geir input appreciated). This route

>>>>>>> would be good because it preserves all the history for us in
one 
>>>>>>> place.
>>>>>>>
>>>>>>> However it does come with a couple of challenges;
>>>>>>>
>>>>>>> a) We have changes in the SVN on apache to get us to AMQ 4.0-
>>>>>>> SNAPSHOT, these changes are not huge but it was several code

>>>>>>> changes and it would be a pain to go back and redo them.
>>>>>>> b) The CVS history has GPL/LGPL related code in it (i.e. the

>>>>>>> JBoss & JGroups stuff) so my guess is that we'd have to do
some 
>>>>>>> selective pruning of the CVS history to make that happen. 
>>>>>>> Perhaps we could do something clever like move the whole history

>>>>>>> set over to svn, then since I'll be moving everything around
to 
>>>>>>> get rid of the stuff me moved to apache I could make 2 sets/
>>>>>>> branches/tags one with the stuff we moved and one without. We

>>>>>>> could then move only the history of the code that was moved.

>>>>>>> Bruce: I'm not sure how complex it is to get history moved from

>>>>>>> one svn repo to another, any thoughts there?
>>>>>>>
>>>>>>> Anyway thanks for sticking with me through this long email. Your

>>>>>>> feedback and thoughts are, as always, welcome.
>>>>>>>
>>>>>>> TTFN,
>>>>>>>
>>>>>>>
>>>>>>> Bill Dudney
>>>>>>> MyFaces - myfaces.apache.org
>>>>>>> Wadi - incubator.apache.org/wadi
>>>>>>>
>>>>>>
>>>>>> --Geir Magnusson Jr                                  +1-203-665-6437
>>>>>> geirm@apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --Geir Magnusson Jr                                  +1-203-665-6437
>>>> geir@optonline.net
>>>>
>>>>
>>>>
>>
>>
>> --"Open Source is a self-assembling organism. You dangle a piece of
>> string into a super-saturated solution and a whole operating-system
>> crystallises out around it."
>>
>> /**********************************
>> * Jules Gosnell
>> * Partner
>> * Core Developers Network (Europe)
>> *
>> *    www.coredevelopers.net
>> *
>> * Open Source Training & Support.
>> **********************************/
>>
>>

Mime
View raw message