[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Git migration and ECF 3.4 timing: PLEASE READ
|
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