[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Move to GIT

On 06/14/2010 08:11 PM, Wim Jongman wrote:
> Hi,
> We have discussed the move to GIT on the conference call. We have agreed
> to move to GIT as soon as possible. There are a couple of things that
> need to be solved in our way of working which we can discuss here:
> One advantage of GIT is to have a staged repository. This means that
> check-ins do not pile up in your workspace but that you can frequently
> commit in your local repository. This sounds good but it comes with its
> own sets of threats. For example, programmers tend to become more
> isolated because their work is not frequently merged to the master
> repository (if somebody again says there is no master repository, I
> start screaming ;). Also, if the programmer loses his/her local disk
> then a lot of changes can get lost because of local only check-ins. In
> contrast check-ins to CVS HEAD require high quality bites of code which
> forces the programmer to think/work like that.
> Markus suggested to have some kind of intermediate repository (lets say
> TEST) where work can be merged and build without breaking the build on
> the master repository. This could even be automated, when the TEST build
> succeeds, all changes are released to the master repository.
> We have talked about the lack of eclipse integration. The CVS
> state-of-the-art is not available in GIT yet but better integration and
> adoption rate should run parallel.  I have worked on some issue a few
> months ago in EGit and they have a really committed team. I expect that
> GIT integration will become better real quick.
> GIT also allows us to use code reviews tools like Gerrit. We have to ask
> the GIT team how this increases the workload, but a bug in one of my own
> contributions was caught early this way so I can state from personal
> experience/shame that this works.


another question is if and how we technically want to move from CVS to
git. For my GSoC project I went with one project/bundle per repo
aggregating a feature set into a parent repo (submodules). Unfortunately
egit/jgit does not support submodules (yet). Other Eclipse projects use
a different approach and host a feature set into a single repo.
IMO the single bundle per repo approach offers the biggest flexibility
while it certainly requires more sophisticated tooling (which is not
there yet in Eclipse).