Why we didn't migrate to Mercurial (long)

[Kevin Bullock]

On Oct 17, 2012, at 3:21 PM, Ciprian Dorin Craciun wrote:

> On Wed, Oct 17, 2012 at 10:12 PM, Arne Babenhauserheide <arne_bab at web.de> wrote:
>> Am Dienstag, 16. Oktober 2012, 14:48:00 schrieb Ciprian Dorin Craciun:
>>>    Thus the question is: when will it be ready and stable?
>> 
>> We cannot answer that yet.
> 
>    Not a problem. Things evolve in time.
> 
> [...]
> 
>> Then the rules would change to
>> 
>> * You always work in the draft phase
>> * Your private repo is non-publishing
> 
>    Yup. So far it changes nothing with the current workflow, except
> that I'm aware of phases and I don't push anything.
> 
>> * Changes which are accepted get pushed into the main repo.
>> The main repo is
>> publishing, so they automatically get changed to public phase.
> 
>    Aha! And here things get mad for me...
> 
>    How do we define "changes are accepted"?
> 
>    (A) In the "big league" of open source projects, I'll have to:
>    * format my patches;
>    * send my patches on the mailing list;
>    * someone will apply them; (the "accepted" event;)
>    * I'll just pull from there;
>    * or most of the times I'll just have to redo the work, which I
> guess won't pose too much trouble from Mercurial;
> 
>    (B) In the "a team of 3 developers" projects I think people usually just:
>    * push the changesets to a "shared" repository (in case of
> Mercurial I guess it is a "feature" repository just for these
> changesets);
>    * ask the others to look over them;
>    * and most of the time they get pulled in the official repository
> by either myself or one of my colleagues (the "gardener" of that
> project); (the "accepted" event;)
>    * I'll just pull happily;
> 
>    In case (A) phases allow me to ditch changesets or rewrite /
> rebase them. But in case (B) which is our current workflow (and I
> guess many "average" developers have this) phases actually don't help
> at all because just by pushing to a repository makes them "published"
> thus I'm unable to "touch" them as they seem to be written in stone...

In your case (B), your "shared" or "feature" repository should also be configured as non-publishing. Then you can happily push draft changesets to it without them being made public.

When someone pulls your changes into the "official" repo (which ought to be publishing), they'll be made public there; when you next pull from the official repo, they'll be made public in your local clone.

>    But of course I might be wrong with all of the above. Thus please
> correct me if I'm wrong.
> 
> 
>>>    And then from the wiki it isn't clear the following:
>>>    * will the changesets actually disappear from the history? (I do
>>> want this, I don't want them just hidden;)
>> 
>> If I recall correctly, there should be a command which vaporizes all the
>> obsolete changesets. And further they should not be pulled if no non-obsolete
>> revision needs them. So people cloning your repo will not see them.
> 
>    Aha. Thus the answer is:
>    * no they don't just disappear completely;
>    * instead they are "hidden" if no other changeset refers to it;
>    * the bonus is that they won't get pulled, thus to
> "garbage-collect" my repository I'll have to create a fresh clone and
> ditch the old one;

That's the idea, yeah.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121017/38479213/attachment-0002.html>