Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  13 Feb 2013, Konstantin Olchanski, Info, Review of github and bitbucket 
    Reply  14 Feb 2013, Stefan Ritt, Info, Review of github and bitbucket 
       Reply  01 Apr 2013, Randolf Pohl, Info, Review of github and bitbucket 
          Reply  02 Apr 2013, Konstantin Olchanski, Info, Review of github and bitbucket 
             Reply  02 Apr 2013, Randolf Pohl, Info, Review of github and bitbucket 
          Reply  03 Apr 2013, Stefan Ritt, Info, Review of github and bitbucket 
             Reply  03 Apr 2013, Randolf Pohl, Info, Review of github and bitbucket 
Message ID: 868     Entry time: 02 Apr 2013     In reply to: 867     Reply to this: 869
Author: Konstantin Olchanski 
Topic: Info 
Subject: Review of github and bitbucket 
Hi, thanks for your positive feedback. I have been using git for small private projects for a few years now
and I like it. It is similar to the old SCCS days - good version control without having to setup servers,
accounts, doodads, etc.

> * No central repo. Have all the history with you on the train.
> * Branching and merging, with stable branches and feature branches.
>   Happy hacking while my students do analysis on a stable version.
>   Or multiple development branches for several features.

This is the part that worries me the most. Without a "central" "authoritative" repository,
in just a few quick days, everybody will have their own incompatible version of midas.

I guess I am okey with your private midas diverging from mainstream, but when *I* end up
with 10 different incompatible versions just in *my* repository, can that be good?

>   And merging really works, including fixing up merge conflicts.

But somebody still has to do it. With a central repository, the problem takes care of
itself - each developer has to do their own merging - with svn, you cannot commit
to the head without merging the head into your code first. But with git, I can just throw
my changes int some branch out there hoping that somebody else would do the merging.
But guess what, there aint anybody home but us chickens. We do not have a mad finn here
to enforce discipline and keep us in shape...

As an example, look at the HADOOP/HDFS code development, they have at least 3 "mainstream"
branches going, neither has all the features combined together and each branch has bugs with
the fixes in a different branch. What a way to run a railroad.

> * "git bisect" for finding which commit introduced a (reproducible) bug.
> * "gitk --all"
>
> Go for git. :-)

Absolutely. For me, as soon as I can wrap my head around this business of "who does all the merging".

K.O.
ELOG V3.1.4-2e1708b5