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

[Jonathan Larmour <jifl at jifvik dot org>]

On 01/05/10 10:23, Alex Schuilenburg wrote:
> On 2010-04-30 16:04, BjÃrn Forsman wrote:
>> 2010/4/29 Jonathan Larmour <jifl@jifvik.org>:
>>> On 29/04/10 14:25, BjÃrn Forsman wrote:
>>>> 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.

Alex made his own reply, but I'll give my slightly different angle: named
branches are meant to be pushed - the point being that that sort of branch
is specifically one that's meant to be kept in sync with upstream. If you
have stuff that isn't meant to be kept in sync, you can use a local
branch. Don't use named branches for things you don't want to share any
more than you would the default (master) branch.

> 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 I think that's an important step which people should be using before
committing - in our case, this is primarily the maintainers.

> 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 don't think that's much of a risk either to be honest.

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

Yes. We don't have to force people to follow a specific workflow, and
there are choices available for different workflows. That being said, hg
gives more choices of workflow (mostly by virtue of being able to choose
between its variety of extensions) than git. For example as well as
mercurial patch queues, there's a different extension called pbranch which
has a different workflow for achieving the same thing.

>> 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.

I guess I'm indeed more concerned about any history changing that affects
what a public repository can see.

I don't want to be prescriptive so what people do on their own machines is
up to them (so for that matter they can use hg if we use git or git if we
use hg). But I think it's important the public repo never changes history.

> 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.

Given what Bjorn says, if it's a local repo only then there's no vanity to
preserve as no-one else would see it :).

> 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.

I think what Bjorn is saying is that as long as it's stuff that happens
before it hits the public repo, then it's immaterial if someone changed
history of their own development work, while it was in progress, along the
way. If that's the only time history-altering stuff happens, then it's no
big deal.

Jifl

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