Re: A Git mirror for Drupal CVS

On Mon, 25 Feb 2008 15:44:56 -0500, Earnie Boyd
<earnieusers.sourceforge.net> wrote:
> Quoting Liam McDermott <liamintermedia-online.com>:
> 
>> Gerhard Killesreiter wrote:
>>> What we coud do (as long as the relevant
backend for the project module
>>> exists) is to move core development to git.
There we are free of social
>>> reasons.
>>
>> This sounds like an excellent idea! The only
problem is having to
>> maintain two seperate version control systems at
the same time. On a
>> related point: if this works for core, would it not
make sense to
>> allow contrib maintainers the option to use Git
instead of CVS?
>>
>> Make Git optional and contrib maintainers can move
over at their own
>> speed. If/when a Windows GUI client becomes
available for example. It
>> would also be interesting to see how many people
stick with CVS, if
>> nearly everyone switches their modules/themes to
Git, CVS could be
>> deprecated pretty quickly.
>>
>> Just throwing some ideas around. Sorry if this has
all been said before.
> 
>>
> 
> Nice idea.  Now all that is left is the work to help
Derek with making
> the transition for the project module.

Except for those people who do checkout anonymously from
core for various reasons and don't want to have to deal with
yet another RCS with completely different semantics...

*raises hand*

--Larry Garfield

On Tuesday, 26. February 2008, Larry Garfield wrote:
> >> Gerhard Killesreiter wrote:
> >>> What we coud do (as long as the relevant
backend for the project module
> >>> exists) is to move core development to
git. There we are free of social
> >>> reasons.
[snip]
>
> Except for those people who do checkout anonymously
from core for various
> reasons and don't want to have to deal with yet another
RCS with completely
> different semantics...

Arguably, this is a prime example of where the git-cvs
bridge would actually 
help instead of complicating stuff. (Can be set up in a
backwards-compatible 
way, no documentation changes needed in order to keep
working, doesn't 
complicate the process for contrib authors.)

Given that core has probably the largest number of patches
that were not 
authored by the committer, and is generally developed in a
more Linux-style 
fashion (few gatekeepers, many branches and patches from
outside - as opposed 
to contrib), I tend to like this proposal and think that
core is probably the 
place where distributed version control would be most
helpful.

--Jakob Petsovits

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Garfield schrieb:
> On Mon, 25 Feb 2008 15:44:56 -0500, Earnie Boyd
<earnieusers.sourceforge.net> wrote:
>> Quoting Liam McDermott <liamintermedia-online.com>:
>>
>>> Gerhard Killesreiter wrote:
>>>> What we coud do (as long as the relevant
backend for the project module
>>>> exists) is to move core development to git.
There we are free of social
>>>> reasons.
>>> This sounds like an excellent idea! The only
problem is having to
>>> maintain two seperate version control systems
at the same time. On a
>>> related point: if this works for core, would it
not make sense to
>>> allow contrib maintainers the option to use Git
instead of CVS?
>>>
>>> Make Git optional and contrib maintainers can
move over at their own
>>> speed. If/when a Windows GUI client becomes
available for example. It
>>> would also be interesting to see how many
people stick with CVS, if
>>> nearly everyone switches their modules/themes
to Git, CVS could be
>>> deprecated pretty quickly.
>>>
>>> Just throwing some ideas around. Sorry if this
has all been said before.
>> 
>> Nice idea.  Now all that is left is the work to
help Derek with making
>> the transition for the project module.
> 
> Except for those people who do checkout anonymously
from core for various reasons and don't want to have to deal
with yet another RCS with completely different semantics...
> 
> *raises hand*

Well, there could be a read-only cvs (or svn) mirror of
core... :p

Cheers,
	Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHw+bofg6TFvELooQRAgfzAJ9P1BrZZ0VcH2eOcvgmlyKK9IYUDgCc
CKPv
5snd4nrXsSAkO5X+QivCc0E=
=trDu
-----END PGP SIGNATURE-----