Re: Git migration timeline

On Mon, Aug 16, 2010 at 15:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> According to the decision at the developer meeting, the migration to
>> git should happen 17-20 Aug. Here's my proposed timeline. This will
>> obviously affect development work some, and since the original
>> timeline called for us having already released 9.0 buy then ;)
>
> Core is currently talking about exactly when we want to push out
> 9.0beta5 and/or 9.1alpha1, and the scheduling of the git transition has
> to wait on that decision.  I don't think we're going to be ready for it
> to begin on Tuesday.  Ignoring the exact timing, this plan sounds good
> except for this bit:

Ok. The sooner you can let me (and others) know, the better.

Note that if it gets pushed past the end of this week (for the whole
process), it's quite likely that the whole process will be stretched
out further. I'll have other committments I need to take care of
meanwhile then - this week i've set of a fair amount of dedicated time
to work on this. Next week, for example, almost all the work would
have to be done durning the evenings (european time) outside  of work
hours, which obviously makes for a lot less available time.


>> 1. Tuesday evening, around 19:00 central european time, which is 17:00
>> GMT or 12:00 EST, I will freeze the current cvs repository. I will do
>> this by disabling committer login on that box, so please note that
>> this will also make it impossible for committers to do a "cvs update"
>> from the authenticated repository.
>
> That's not really going to do, especially since it will also lock out
> "cvs log".  I certainly want to do a final update and cvs2cl after the
> last commits have happened, and I imagine other people will want that
> too.  If there were a way to make the repository read-only that would be
> nice, but I think what we're going to need to settle for is relying on
> the committers to not do any more commits after the specified time.

You can still rsync the copy off the anoncvs server (or use the
anoncvs one). That one is an exact rsync of the main one, so I don't
see why something like "cvs2cl" wouldn't work off that one
automatically. I was just assuming every developer was already using
an rsynced copy for that kind of work :-)

I would like to make the repo readonly if I could, but I don't know a
reliable way of doing that with cvs. If someone can enlighten me on
one, that's obviously preferred.


> I can see the point of wanting to be dead certain the repository isn't
> changing under you during the data migration.  Perhaps we need an agreed
> window between last call for commits and the actual lock-out.

To prevent that, I just need to shut it down for 2 minutes to rsync
the latest changes off it and onto the new git box. Maybe that's how
we should do it.

This is a defense against committers forgetting about things and
accidentally committing to the repository *after* it's been
snapshotted. I guess we can just declare those as ignorant and throw
away those commits.. :-)


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/