Moving to Git

[Simone Bordet]

Hi,

we are seriously considering to move to Git as a SCM, and to GitHub as
a Git host.
I would like to share some idea about the best way to re-organize the
project when doing the move.

Currently we have SVN /trunk, where CometD 2 is developed, and SVN
branch /branches/cometd1 where CometD 1 is maintained.
We also have other branches, but can be ignored as they are obsolete.

We mount 4 SVN externals for the perl implementation, but I think it
is outdated, and it is anyway maintained elsewhere, so my guess is
that we can drop it.
I will contact Xantus in any case, as it seems the major contributor
to the Perl implementation.

We have the python implementation, but that also is not maintained
anymore, so perhaps we can leave it in SVN, or port it to git as well.

My current thoughts are to create 2 main git repositories: cometd1.git
and cometd2.git (and eventually a cometd-python.git).

I do not see any reason to have only one cometd.git repository with
branches for cometd1 and cometd2, since the codebases have diverged
quite a lot and I do not think there will be merges between the two,
so it really is like having two projects.
However, I do not have much experience in porting projects from SVN to
Git, so any hint you may have on this is greatly appreciated.
The doubt that I have is that if we had started CometD using Git
instead of SVN, now we would have those 2 branches in a single Git
repository. But that does not mean we have to do it now.
Thoughts ?

Regarding the branching model, I am now using for other projects
something similar to this:
http://nvie.com/posts/a-successful-git-branching-model/.
I have a "master" branch that keeps the stable code (the last
release), and a "develop" branch that roughly correspond to SVN's
trunk.
Given that the project is small with few committers, I fear that this
model may be too complicated: we can just keep the "master" branch as
the correspondent for SVN trunk, and use Git tags for releases.
Any thought/suggestion on this ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

[Greg Wilkins]

Hey Simone,

I would consider leaving cometd-1 in SVN. We don't really want to
encourage further development of cometd-1, as cometd-2 can run on all
the same platforms and is much much better.

I think the master==trunk model is the best way to proceed, as that
encourages us to keep trunk working. We can create branches as needed
(privately or in github) for individual developments.

cheers

> --
> You received this message because you are subscribed to the Google Groups "cometd-dev" group.
> To post to this group, send email to comet...@googlegroups.com
> To unsubscribe from this group, send email to cometd-dev-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/cometd-dev
>
> Visit the CometD website at http://www.cometd.org
>

[Simone Bordet]

Hi,

On Mon, May 16, 2011 at 03:16, Greg Wilkins <gr...@wiltel.org> wrote:
> Hey Simone,
>
> I would consider leaving cometd-1 in SVN.   We don't really want to
> encourage further development of cometd-1, as cometd-2 can run on all
> the same platforms and is much much better.
>
> I think the master==trunk model is the best way to proceed, as that
> encourages us to keep trunk working.  We can create branches as needed
> (privately or in github) for individual developments.

After some fiddling, I have managed to get a local git version of
CometD 2 obtained from the current SVN trunk, cleaned up the SVN bits
(so that it looks like native Git, like explained here:
http://maururu.net/2009/svn-to-git-take-2/) and kept only CometD 2
tags.
I am ready to push to GitHub, if there are no further comments
(especially from Git experts).
With the push we will have CometD 2 hosted at GitHub, on a "master"
branch only (as suggested by Greg).
CometD 1, cometd-perl and cometd-twisted will remain in the current
SVN repository.

I think will be good to call the GitHub repo "cometd.git" (and not
cometd2.git) so that if we ever have a CometD 3 before some other SCM
replaces Git, we will have a better named repository.

Other thoughts or things that I may have missed ?

[Greg Wilkins]

On Wed, May 18, 2011 at 07:50, Simone Bordet <sbo...@intalio.com> wrote:
> I think will be good to call the GitHub repo "cometd.git" (and not
> cometd2.git) so that if we ever have a CometD 3 before some other SCM
> replaces Git, we will have a better named repository.

+1

[Simone Bordet]

Hi,

On Tue, May 17, 2011 at 23:50, Simone Bordet <sbo...@intalio.com> wrote:
> After some fiddling, I have managed to get a local git version of
> CometD 2 obtained from the current SVN trunk, cleaned up the SVN bits
> (so that it looks like native Git, like explained here:
> http://maururu.net/2009/svn-to-git-take-2/) and kept only CometD 2
> tags.
> I am ready to push to GitHub, if there are no further comments
> (especially from Git experts).
> With the push we will have CometD 2 hosted at GitHub, on a "master"
> branch only (as suggested by Greg).
> CometD 1, cometd-perl and cometd-twisted will remain in the current
> SVN repository.
>
> I think will be good to call the GitHub repo "cometd.git" (and not
> cometd2.git) so that if we ever have a CometD 3 before some other SCM
> replaces Git, we will have a better named repository.

I have completed the move to GitHub for CometD 2:
https://github.com/cometd/cometd

Work on CometD 2 will now happen there, on branch "master". No other
branches for now.

[bryan hunt]

> Work on CometD 2 will now happen there, on branch "master". No other
> branches for now.
>
> Simon

Good move dude! SVN sux!