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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
