You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2004/07/14 15:17:51 UTC
Traditional 'Branch'
All,
We've discussed various ways to separate Traditional from Python, so we can
re-organize directories, clean-up and focus on extensions to the current
base. We've discussed moving Python Gump out to SVN, and we've discussed
moving the metadata to a separate CVS module. I suspect these will be a bit
of logistical pain, although worth doing one day.
I wonder if the following has some mileage (at least as a transitional
solution). Create a branch for Traditional, and leave that branch in place
long term. I do not know CVS well enough to know if this is poor form (if
branches ought be short term) but the merits are that folks who wish to keep
traditional can change their CVS tag to get it, but can also fix and minor
nits, etc.
If we did this, I'd like to start cleaning up the root directories, removing
things no longer used (which would make my modem happy on checkouts), and
perhaps moving the python sub-directories' contents up one.
Thoughts?
regards
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by Stefano Mazzocchi <st...@apache.org>.
Martin van den Bemt wrote:
> Thought I just read on infrastructure that they setup a document on how
> to migrate and looking for people who want to do that, so in the light
> of your migration experience, maybe it's an option that you can move cvs
> over to svn.
I really don't have time to follow up on that now, sorry :-/
--
Stefano.
Re: Traditional 'Branch'
Posted by Martin van den Bemt <ml...@mvdb.net>.
Thought I just read on infrastructure that they setup a document on how
to migrate and looking for people who want to do that, so in the light
of your migration experience, maybe it's an option that you can move cvs
over to svn.
Mvgr,
Martin
On Fri, 2004-07-16 at 07:08, Stefano Mazzocchi wrote:
> Adam R. B. Jack wrote:
>
> > Nicola wrote;
> >
> >
> >>Stefano Mazzocchi wrote:
> >>...
> >>
> >>>Ok, what about moving all the code to subversion and just keep the
> >>>metadata in CVS? (at least for now)
> >>
> >>IIRC that what we had basically agreed was a sensible thing to do for
> >>Python Gump.
> >>
> >>+1 from me
> >
> >
> > Yeah, I think we agree that is the best mid-term solution, I was just (1)
> > nervous about making an SVN request ('cos of delays in getting the resources
> > configured/converted)
>
> I'm not following infra@ anymore so I can't comment on that, but I've
> done the migration of several CVS modules myself and I think the
> conversion of gump would be rather easy and fast. We might want to point
> that out to infra@ when we request it.
>
> (2) hoping to clean out/re-organize now (prior to any
> > such 1 above).
>
> I would strongly suggest to reconsider that. the ability to move stuff
> around is a *great* way to refactor without loosing any historical
> information.
>
> >
> > I guess I could tag the current tree as TRADITONAL, communicate (not sure
> > how) with any traditional users to use that tag. and then start cleaning out
> > CVS HEAD whilst infr (or member w/ karma) schedules a CVS to SVN move. The
> > branch just seems like a nice way to separate traditional out (in case
> > anybody chose to fix metadata and/or code), i.e. giving more options. Both
> > ways would cause work for anybody trying to maintain a traditional.
>
> I see no reason to touch the existing CVS module. Just have everything
> migrated over and then start cleaning up, moving things around or
> deleting things.
>
> Believe me, SVN is *sweet* for that.
>
> >
> > Don't forget, I'm one of the poor sods who doesn't have a lot of fun w/ SVN
> > (especially w/ Eclipse 3.0 over a modem). For me CVS is more
> > reliably/robust/functional. This was also part of my reticence, but I can
> > get by that -- since I believe in moving w/ the flow of the new (so out w/
> > the old).
>
> weird, my experience (eclipse 3.0 over dsl) is that svn feels a lot
> faster than CVS.
>
> > Big questions (1) folks ok w/ me doing a clean/re-org prior to importing
> > into SVN? I hope so. (2) do we want to preserver history? [There is a lot of
> > junk in there from me, in part due to me not being able to fully test
> > locally.]
>
> I would strongly advocate for a migration first and then cleanup rather
> than the other way around. Remember: one day this could be of historical
> value! never throw away data if you can avoid it!
>
> > BTW: I would like to cut down on the number of commits I do that I then have
> > to follow up with N minor 'fixit' commits. [Heck, reduce embarrassment, as
> > well as CVS history junk.] The reason I do these (unintentionally) is I
> > test Gump from CVS on a remote server, and I can't (network bandwidth over
> > modem), do anything but unit tests locally. I guess I could figure out a way
> > to rsync from my local dev area to a remote server to test, then commit, the
> > sad news is that would be twice the traffic. Any thoughts, or is rsynch it?
>
> my workflow suggestion is:
>
> 1) have infra@ migrate the existing gump CVS over to SVN
>
> 2) do your checkout with svn
>
> 3) do the cleanup (move files around, prune files that shouldn't be
> there, etc...) [doesn't matter if it's not functional, CVS is still in
> place]
>
> 4) then start working on the code. [at that point, people will know
> not to touch stuff in CVS if not the metadata... we can also remove
> everything from that CVS module but the metadata]
>
> comments?
--
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> my workflow suggestion is:
>
> 1) have infra@ migrate the existing gump CVS over to SVN
I assume we have all Apache w/ access to this SVN repository, i.e. same
perms as CVS.
No brainer, but I assume we want:
https://svn.apache.org/repository/gump/
Any other input we give to infr?
> 2) do your checkout with svn
>
> 3) do the cleanup (move files around, prune files that shouldn't be
> there, etc...) [doesn't matter if it's not functional, CVS is still in
> place]
>
> 4) then start working on the code. [at that point, people will know
> not to touch stuff in CVS if not the metadata... we can also remove
> everything from that CVS module but the metadata]
5) I will tag as TRADITIONAL (FWIIW) and then remove all extras. I can't
cope w/ the 1+Mb XERCES checkout that I don't use. I also agree that
cleaning up to only have the metadata will make this a lot more acessible to
folks.
> comments?
I guess we then just document CLEARLY (in multiple places) that (1) code is
called 'gump' in SVN and (2) metadata is called 'gump' in CVS (and one day
metadata will reside in SVN).
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
> Nicola wrote;
>
>
>>Stefano Mazzocchi wrote:
>>...
>>
>>>Ok, what about moving all the code to subversion and just keep the
>>>metadata in CVS? (at least for now)
>>
>>IIRC that what we had basically agreed was a sensible thing to do for
>>Python Gump.
>>
>>+1 from me
>
>
> Yeah, I think we agree that is the best mid-term solution, I was just (1)
> nervous about making an SVN request ('cos of delays in getting the resources
> configured/converted)
I'm not following infra@ anymore so I can't comment on that, but I've
done the migration of several CVS modules myself and I think the
conversion of gump would be rather easy and fast. We might want to point
that out to infra@ when we request it.
(2) hoping to clean out/re-organize now (prior to any
> such 1 above).
I would strongly suggest to reconsider that. the ability to move stuff
around is a *great* way to refactor without loosing any historical
information.
>
> I guess I could tag the current tree as TRADITONAL, communicate (not sure
> how) with any traditional users to use that tag. and then start cleaning out
> CVS HEAD whilst infr (or member w/ karma) schedules a CVS to SVN move. The
> branch just seems like a nice way to separate traditional out (in case
> anybody chose to fix metadata and/or code), i.e. giving more options. Both
> ways would cause work for anybody trying to maintain a traditional.
I see no reason to touch the existing CVS module. Just have everything
migrated over and then start cleaning up, moving things around or
deleting things.
Believe me, SVN is *sweet* for that.
>
> Don't forget, I'm one of the poor sods who doesn't have a lot of fun w/ SVN
> (especially w/ Eclipse 3.0 over a modem). For me CVS is more
> reliably/robust/functional. This was also part of my reticence, but I can
> get by that -- since I believe in moving w/ the flow of the new (so out w/
> the old).
weird, my experience (eclipse 3.0 over dsl) is that svn feels a lot
faster than CVS.
> Big questions (1) folks ok w/ me doing a clean/re-org prior to importing
> into SVN? I hope so. (2) do we want to preserver history? [There is a lot of
> junk in there from me, in part due to me not being able to fully test
> locally.]
I would strongly advocate for a migration first and then cleanup rather
than the other way around. Remember: one day this could be of historical
value! never throw away data if you can avoid it!
> BTW: I would like to cut down on the number of commits I do that I then have
> to follow up with N minor 'fixit' commits. [Heck, reduce embarrassment, as
> well as CVS history junk.] The reason I do these (unintentionally) is I
> test Gump from CVS on a remote server, and I can't (network bandwidth over
> modem), do anything but unit tests locally. I guess I could figure out a way
> to rsync from my local dev area to a remote server to test, then commit, the
> sad news is that would be twice the traffic. Any thoughts, or is rsynch it?
my workflow suggestion is:
1) have infra@ migrate the existing gump CVS over to SVN
2) do your checkout with svn
3) do the cleanup (move files around, prune files that shouldn't be
there, etc...) [doesn't matter if it's not functional, CVS is still in
place]
4) then start working on the code. [at that point, people will know
not to touch stuff in CVS if not the metadata... we can also remove
everything from that CVS module but the metadata]
comments?
--
Stefano.
Re: Traditional 'Branch'
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> CVS can be preserved, but down the line it will be frozen and probably
> disabled and archived, this will make it much harder for them to have
> access to this historical information.
It also dawned on me that once we finally decide to migrate Gump metadata
also to SVN, and disable/archive CVS, we'll have nowhere to cvs2svn the code
history (since the SVN code repository would already be up and running).
> These digital historians are our friends, we should treat them well ;-)
I agree.
As such, I agree to :
> No, please, do this instead:
>
> 1) We ask for a gump tree in SVN [letting them know we'll keep the gump
module in CVS]
> 2) use cvs2svn to migrate gump CVS over gump SVN
> 3) tag gump CVS as "PRE_SVN_MIGRATION"
> 4) remove everything from gump CVS that is not metadata
> 5) cleanup the gump SVN repository as you wish
And I appreciate this next :)
> All right, I volunteer to help with 2).
I figure we've most likely heard from as many people as are intimate and
care, we have a suitable consensus, and this has been out there long enough
(weeks) if others had alternate opinions. As such, so I'll proceed with the
request to infrastructure, under the unofficial basis of JFDI (Just ... do
it) and copy pmc@gump in case folks differ.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by Stefano Mazzocchi <st...@apache.org>.
Stefan Bodewig wrote:
> As long as we keep the history of "traditional" in CVS I don't care
> too much whether it gets migrated to SVN at all. It's not as if we'd
> remove the CVS module completely, it will just become unused.
Several people I know here at MIT are working on tools for data
analysis, sort of digital archeology projects. Migrating everything in
one shot will make them a lot happier and will not hurt us at all.
CVS can be preserved, but down the line it will be frozen and probably
disabled and archived, this will make it much harder for them to have
access to this historical information.
These digital historians are our friends, we should treat them well ;-)
--
Stefano.
Re: Traditional 'Branch'
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
>>>(2) hoping to clean out/re-organize now (prior to any such 1 above).
>>
>>As long as we keep the history of "traditional" in CVS I don't care
>>too much whether it gets migrated to SVN at all. It's not as if we'd
>>remove the CVS module completely, it will just become unused.
>
>
> I think this is a key point, especially since the cvs2svn run is likely the
> big bottleneck w/ infra@. I'd like to get one last clarification before I
> write to infr@ (and copy pmc@gump).
>
> 1) We ask for a gump tree in SVN [letting them know we'll keep the gump
> module in CVS.]
> 2) We mark tag gump CVS as 'TRADITIONAL'.
> 3) We remove all the older/unused (traditional) contents, and we move all
> Python code to SVN, leaving only the metadata directories.
> 4) We commit Python to SVN.
>
> Good enough for folks?
No, please, do this instead:
1) [fine]
2) use cvs2svn to migrate gump CVS over gump SVN
3) tag gump CVS as "PRE_SVN_MIGRATION"
4) remove everything from gump CVS that is not metadata
5) cleanup the gump SVN repository as you wish
All right, I volunteer to help with 2).
--
Stefano.
Re: Traditional 'Branch'
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 19 Jul 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
> 1) We ask for a gump tree in SVN [letting them know we'll keep the
> gump module in CVS.]
> 2) We mark tag gump CVS as 'TRADITIONAL'.
> 3) We remove all the older/unused (traditional) contents, and we
> move all Python code to SVN, leaving only the metadata directories.
> 4) We commit Python to SVN.
works for me.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > (2) hoping to clean out/re-organize now (prior to any such 1 above).
>
> As long as we keep the history of "traditional" in CVS I don't care
> too much whether it gets migrated to SVN at all. It's not as if we'd
> remove the CVS module completely, it will just become unused.
I think this is a key point, especially since the cvs2svn run is likely the
big bottleneck w/ infra@. I'd like to get one last clarification before I
write to infr@ (and copy pmc@gump).
1) We ask for a gump tree in SVN [letting them know we'll keep the gump
module in CVS.]
2) We mark tag gump CVS as 'TRADITIONAL'.
3) We remove all the older/unused (traditional) contents, and we move all
Python code to SVN, leaving only the metadata directories.
4) We commit Python to SVN.
Good enough for folks?
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by Stefan Bodewig <bo...@apache.org>.
> Nicola wrote;
>
>> Stefano Mazzocchi wrote:
>> ...
>> > Ok, what about moving all the code to subversion and just keep
>> > the metadata in CVS? (at least for now)
>>
>> IIRC that what we had basically agreed was a sensible thing to do
>> for Python Gump.
>>
>> +1 from me
+1 from me as well.
On Thu, 15 Jul 2004, Adam R. B. Jack <aj...@apache.org> wrote:
> Yeah, I think we agree that is the best mid-term solution, I was
> just (1) nervous about making an SVN request ('cos of delays in
> getting the resources configured/converted)
No problem.
> (2) hoping to clean out/re-organize now (prior to any such 1 above).
As long as we keep the history of "traditional" in CVS I don't care
too much whether it gets migrated to SVN at all. It's not as if we'd
remove the CVS module completely, it will just become unused.
> Big questions (1) folks ok w/ me doing a clean/re-org prior to
> importing into SVN?
See above.
> (2) do we want to preserver history?
Yes.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by "Adam R. B. Jack" <aj...@apache.org>.
Nicola wrote;
> Stefano Mazzocchi wrote:
> ...
> > Ok, what about moving all the code to subversion and just keep the
> > metadata in CVS? (at least for now)
>
> IIRC that what we had basically agreed was a sensible thing to do for
> Python Gump.
>
> +1 from me
Yeah, I think we agree that is the best mid-term solution, I was just (1)
nervous about making an SVN request ('cos of delays in getting the resources
configured/converted) (2) hoping to clean out/re-organize now (prior to any
such 1 above).
I guess I could tag the current tree as TRADITONAL, communicate (not sure
how) with any traditional users to use that tag. and then start cleaning out
CVS HEAD whilst infr (or member w/ karma) schedules a CVS to SVN move. The
branch just seems like a nice way to separate traditional out (in case
anybody chose to fix metadata and/or code), i.e. giving more options. Both
ways would cause work for anybody trying to maintain a traditional.
Don't forget, I'm one of the poor sods who doesn't have a lot of fun w/ SVN
(especially w/ Eclipse 3.0 over a modem). For me CVS is more
reliably/robust/functional. This was also part of my reticence, but I can
get by that -- since I believe in moving w/ the flow of the new (so out w/
the old).
Big questions (1) folks ok w/ me doing a clean/re-org prior to importing
into SVN? I hope so. (2) do we want to preserver history? [There is a lot of
junk in there from me, in part due to me not being able to fully test
locally.]
BTW: I would like to cut down on the number of commits I do that I then have
to follow up with N minor 'fixit' commits. [Heck, reduce embarrassment, as
well as CVS history junk.] The reason I do these (unintentionally) is I
test Gump from CVS on a remote server, and I can't (network bandwidth over
modem), do anything but unit tests locally. I guess I could figure out a way
to rsync from my local dev area to a remote server to test, then commit, the
sad news is that would be twice the traffic. Any thoughts, or is rsynch it?
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
> Ok, what about moving all the code to subversion and just keep the
> metadata in CVS? (at least for now)
IIRC that what we had basically agreed was a sensible thing to do for
Python Gump.
+1 from me
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
>>Go for it.
>>
>>SVN rulez and it's very well integrated with IDEs now and many apache
>>projects are moving.
>>
>
>
> I read this to mean you'd like to see Gump migrated to SVN. I could read
> your respones as saying, do my 'CVS branch' step first, since it is a move
> in the general directon, but I am guessing I'm stretching your intentions.
> Could you re-read and see that I meant, do a long lived CVS branch for
> Traditional, whilst I clean-up CVS HEAD to be pure Python, prior to a future
> SVN move.
ops, maybe I misunderstood your intentions.
>>And, besides, there is not that thousands of people updating their
>>descriptors anyway ;-)
>
>
> Yeah, but concensus was -- if SVN was a barrier for anybody (and we know it
> is becoming less and less w/ more projects in SVN) we ought keep metadata in
> CVS for a while longer.
Ok, what about moving all the code to subversion and just keep the
metadata in CVS? (at least for now)
People, comments?
--
Stefano.
Re: Traditional 'Branch'
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Go for it.
>
> SVN rulez and it's very well integrated with IDEs now and many apache
> projects are moving.
>
I read this to mean you'd like to see Gump migrated to SVN. I could read
your respones as saying, do my 'CVS branch' step first, since it is a move
in the general directon, but I am guessing I'm stretching your intentions.
Could you re-read and see that I meant, do a long lived CVS branch for
Traditional, whilst I clean-up CVS HEAD to be pure Python, prior to a future
SVN move.
> And, besides, there is not that thousands of people updating their
> descriptors anyway ;-)
Yeah, but concensus was -- if SVN was a barrier for anybody (and we know it
is becoming less and less w/ more projects in SVN) we ought keep metadata in
CVS for a while longer.
> Actually, i think that a better refactoring of the repository could help
> people getting up to speed too, because the tree is currently a mess.
That I do believe! [I also hate having to download a big fat Java xerces
that I never use any more.]
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Traditional 'Branch'
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
> All,
>
> We've discussed various ways to separate Traditional from Python, so we can
> re-organize directories, clean-up and focus on extensions to the current
> base. We've discussed moving Python Gump out to SVN, and we've discussed
> moving the metadata to a separate CVS module. I suspect these will be a bit
> of logistical pain, although worth doing one day.
>
> I wonder if the following has some mileage (at least as a transitional
> solution). Create a branch for Traditional, and leave that branch in place
> long term. I do not know CVS well enough to know if this is poor form (if
> branches ought be short term) but the merits are that folks who wish to keep
> traditional can change their CVS tag to get it, but can also fix and minor
> nits, etc.
>
> If we did this, I'd like to start cleaning up the root directories, removing
> things no longer used (which would make my modem happy on checkouts), and
> perhaps moving the python sub-directories' contents up one.
>
> Thoughts?
Go for it.
SVN rulez and it's very well integrated with IDEs now and many apache
projects are moving.
And, besides, there is not that thousands of people updating their
descriptors anyway ;-)
Actually, i think that a better refactoring of the repository could help
people getting up to speed too, because the tree is currently a mess.
--
Stefano.