Re: [ECOS] Replacing CVS - decision time: part 2

[Alex Schuilenburg <alexs at ecoscentric dot com>]

On 2010-04-30 16:04, BjÃrn Forsman wrote:
> Hi Jonathan,
>
> 2010/4/29 Jonathan Larmour <jifl@jifvik.org>:
>   
>> On 29/04/10 14:25, BjÃrn Forsman wrote:
>>     
>>> Hi,
>>>
>>> 2010/4/28 Alex Schuilenburg <alexs@ecoscentric.com>:
>>>       
>>>> On 2010-04-28 20:26, BjÃrn Forsman wrote:
>>>>         
>>>>> [,,,]
>>>>> Git may be worse than hg on Windows, but IMHO git has better branching
>>>>> and tagging.
>>>>>
>>>>>           
>>>> Could you please explain why you think git has better branching and tagging?
>>>>         
>>> This below is what I *think* is correct, based on my current knowledge. It
>>> may very well be wrong. If so, maybe someone will enlighten me?
>>>
>>> hg branching (skipping unnamed branches and entire repo forks/clones):
>>> * either bookmark branches (local branch)
>>> * or named branches (global branch)
>>>
>>> A hg bookmark is a lightweight branch that can only be used locally. It
>>> cannot be pushed to another repo. A named branch can be pushed to another
>>> repo. So when using hg one would have to choose branch type at branch
>>> creation time. With git you create branches and later choose to push them
>>> if you want to.
>>>       
>> A branch is just a pointer to a revision head. So if you have an hg
>> lightweight branch (bookmark) and you want to be able to push it, all you
>> should need to do is set the branch based on the bookmark.
>>     
> So in effect, there is no need to choose branch type up front then. I
> didn't know that. But I still think it's cleaner to have one branch
> type, like git has. (Ok, I know about remote branches, but... they are
> remote... It just feels like a different thing.)
>   
I disagree.  In a commercial environment with multiple projects there
are a wide variety of demands that are placed on the DRCS. I certainly
have made use of all the different branch types and each has been very
useful in the context it was required.  hg is stronger than git with
respect to branches IMHO, which is why I originally posed my question to
you.

[...]
>>> You can also push specific branches, not just all at
>>> once like hg does.
>>>       
>> hg push -b <branch>
>>     
> I didn't know about that. However, wouldn't it be an accident waiting to
> happen if the SCM system *defaults* to push everything? IMHO git seems
> a bit safer in this respect.
>   
I disagree. Think about it in opposite terms.  When you pull, surely you
want all the changes, not just the branch you are currently checked
out?  So why should pushing be different?  Also, why should the current
state of your working directory have any bearing on the repository when
you push/pull? All you are doing is synchronising what is under the hood
so that it is available to you when you want.

Mercurial to me seems more open in this respect. If you don't want your
changes published, you should be using mercurial queues or lcocal
branches.  You can check what changes will be published with the
outgoing command and you always get prompted if you push a new branch
(so little risk in publishing a branch until you are ready). IMHO there
is a greater risk of something being forgotten if only your current
branch is pushed.

I guess it really comes down to the way you use the DRCS.



>>> You can also rename git branches. Hg named branches are stored as
>>> metadata in changesets which makes it impossible to rename them.
>>> Named branches cannot be deleted either, only hidden.
>>>       
>> This is for the excellent principle that named branches are first class
>> revision-controlled objects and history should not be mutable. You should
>> not be able to easily change history in a version control system. If
>> you're using named branches, that's presumably because you want to be able
>> to push them, in which case they should be under version control just as
>> much as anything else.
>>     
> Maybe we feel a bit differently about what a SCM system should be able
> to do with respect to history. I think git's ability to change history
> is one of its best features. Without it I would feel like a Unix shell
> user without the 'rm' command. Note that git is a *lot* less dangerous
> than a pure 'rm' command. Git operations that are said to change or
> delete history is really just about creating a new alternative history.
> The old history is still there and you must run 'git gc --prune' if you
> want to clean up unreferenced history. And even that command does not
> delete commits that are younger than 2 weeks or so (configurable). So it
> is virtually impossible to do something that is not undoable. Every git
> user knows (or should know!) that rebasing (changing history) should
> never be done in public repos. It's just something to help you manage
> you local repo. git would never change history behind you back. For
> instance, if someone broke the rule and changed history in a public
> repo, others pulling from that repo will be able to figure it out.
>   
Rewriting history is IMHO very very dangerous and defeats the purpose of
a RCS.  That purpose is after all to track changes to your code.  IMHO
this ability to change history is more about protecting an individual's
vanity than anything else. If you need to work at a level where you are
fixing typo's in commits, then you are IMHO using the DRCS incorrectly. 
You should be using queues for tracking rapid prototyping and you should
be making sure that your commits do not break the code base, and if they
do (accidents do happen), then a full history of how to fix it is
preserved for those who ended up with the broken code.

Yes, you can recover in git, just like taking backups. But why should
anyone need to figure anything out?  If you don't hand out rope, people
will not hang themselves...

IMHO you should not be able to rewrite history in a shared repository,
period.  That is asking for confusion and trouble. If we want eCos users
to use the eCos public repository to make commercial products based on
eCos, which we do, you should not be able to mess them around. When
making and supporting commercial releases, one of the *most* important
things is to be able to reproduce what is shipped to a customer.  You
should not have to play around with tarballs of sources to ensure that
you can create a working directory with the same state as what was
shipped.  I cannot think of a single instance when you would want
anything different.  If you make a mistake, you need to track how the
mistake was fixed so those effected have a history of what went wrong
and what the fix is, not for history to be rewritten so the mistake can
be hidden.



>> That said, it is evidently possible to do so if you jump through some hoops:
>> http://mercurial.selenic.com/wiki/PruningDeadBranches
>> but really marking the old branch inactive (the first option) would be the
>> best option. If you don't want to see inactive branches by default in the
>> output of 'hg branches' you can add this to ~/.hgrc:
>>
>> [defaults]
>> branches = -a
>>     
> It seems hg is gaining git features bit by bit. I'm particularly
> thinking about rebasing and the staging area, and as you note, branch
> deletion. hg and git really seem to converge over time.
>   
Both gain each other's features over time IMHO, which is a good thing.

This is why anyone arguing in terms of functionality that hg is better
than git or git is better than hg is likely going to be wrong in a
couple of months.

I'll give you that git has more of it's internals exposed so that some
operations can be done with fewer commands, but that really is only of
benefit to a small handful of power-users.  In these respects it will be
like putting a novice driver behind the wheel of a dragster when all
they want to get is from A to B and if you give people enough rope...   
And of course the power-users will not lose out because of hg-git or
git-hg or whatever...

The choice comes down more to usability, workflow, documentation and
platform support IMHO. This is where hg does shine a bit more than git.

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
Tel:  +44 1223 245571                     Barnwell House, Barnwell Drive
Fax:  +44 1223 248712                             Cambridge, CB5 8UU, UK
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss