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]
