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.
smime.p7s
Description: S/MIME Cryptographic Signature
