Re: [ecf-dev] Git migration and ECF 3.4 timing: PLEASE READ

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

On 08/03/2010 12:25 PM, Wim Jongman wrote:
> 
>         d) So the bottom line, I believe, is that once we do the
>         changeover that we should effectively plan on *shutting off CVS
>         access* in favor of the git repo *only*.  The reason we think
>         this will be easier is because even if we try to sync the CVS
>         repo with the git repo (i.e. 'b'), it will be a lot of work to
>         do so frequently enough to make it worthwhile...as Eclipse IT
>         won't do it for us, we won't be able to automate it, and we
>         don't currently have the resource for us to do it manually with
>         very high frequency
> 
> Do we need access to the CVS machine to run the cron job? Can't we fire
> a job on an intermediate machine that syncs cvs with git?

Aside from the system and network load (btw. see bug #321556 [0]), you
will have to:

a) make sure nobody writes to CVS anymore (that is something only the
webmaster can do)
b) make sure git to CVS sync works correctly

For b) git-cvsexportcommit might help, but IIRC I read about cases where
patches/commits/changes created in git won't apply cleanly to CVS (think
branches/tags/...).

All in all it will cause constant work to even keep a read only CVS
mirror of our git repo. Not sure the benefits outweigh this work.

Personally I don't even see the need to keep a CVS repo in the first
place. For a consumer what's the difference between "cvs co $REPO" and
"git clone $REPO"? This might sound ignorant, but if consumers want to
make sense out of ECF, they should at least be able to use a SCM.
Otherwise they will fail with ECF anyway. %)

Markus

[0] https://bugs.eclipse.org/bugs/321556