Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Mon, Apr 15, 2013 at 2:52 AM, Christopher Felton
<chr...@gm...> wrote:
> On 4/14/13 2:48 PM, Angel Ezquerra wrote:
>> On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
>>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>>
>>>> Oscar,
>>>>
>>>> if you have never used mercurial and need some help drop me a line. I
>>>> am very active in TortoiseHg development (and a bit on mercurial as
>>>> well) so I think I could help bring you up to speed if you need it
>>>
>>> Interesting.
>>>
>>> Perhaps I should ask a more general question: should we
>>> consider to move MyHDL development to github?
>>>
>>> This is not a technical question. Many Pythonistas probably
>>> have a slight preference for Python-based mercurial.
>>> Professionally, I use both and I am happy with either one.
>>>
>>> The point is that "everyone" seems to be at github. So
>>> perhaps this is good for visibility.
>>>
>>> It may also be good for development. I like the way
>>> Oscar presented his work: it shows commitment to
>>> maintain the feature, and everyone can try/follow
>>> it without requiring my assistance. Much better
>>> than getting patches/bundles out of the blue that
>>> I am supposed to review/check/integrate before others
>>> can (easily) do so.
>>>
>>> Of course, for this to work, all development should
>>> be on the same system.
>>>
>>> Jan
>>
>>
>> As you an imagine given my background I really like the fact that
>> MyHDL is developed using mercurial, which I greatly prefer over git.
>>
>> This is a bit off topic but I personally find the fact that so many
>> technical people use and even advocate git rather than mercurial both
>> surprising and a little depressing, since (IMHO) mercurial is a much
>> better all around version control system (_much_ better UI, better
>> tools, better Windows support, better, simpler model, etc). I think
>> github is a big reason why git is more popular than mercurial (at the
>> time github was created, there was nothing quite like it, unless you
>> count SourceForge...) but the real reason is probably the fact that it
>> was created by Linus... I guess we technical people are as prone to
>> decide things based on non technical reasons as anybody else...
>
> Can you outline some of the technical pros?  From what I have been
> able to gather it is somewhat subjective.  It seems both projects
> have been influence each other resulting in technical equals.
>
> I have found some short coming with git and my work flow but I assume
> that was me being less familiar with git than hg.

Sorry it took me a long time to reply to this. I've been quite busy as of late.

At their base, git and mercurial are quite similar. However they
differ in some important details, some of which make git the less
reliable tool. In particular:

1. mercurial supports anonymous branches (i.e. non linear branches).
This has the very good side effect of making the "pull" operation
completely safe, which is not the case in git I believe. Let me give
you an example:

Imagine a scenario were Alice and Bob are using git and they are
collaborating on the same feature. Both of them are working on the
same feature branch. Alice makes a few local commits but doesn't push
them yet. Bob colleague does a few commits on his own PC and pushes
them to master. When Allice pulls from master her local commits are
automatically rebased on top Bob's commits. Even assuming that the
rebase goes perfectly, Alice's  original commits are gone! That is,
the code that Alice originally committed is not the same code that she
has now. As far as I know there is no way to get the original commits
back. This is (IMHO) extremely unsafe.

Compare that with the same scenario in mercurial. When you Alice pulls
from the central repo (let's call it default) she just gets Bob's
commits as a new anonymous branch (with a new head). Then Alice can,
at her own leisure, just do a merge between her anonymous branch and
the one she got from Bob. Her old commits are still there and she can
come back to them whenever she wants to. She also has the option to do
a rebase, in which case the result would be the same as in git, but
that is just an option, and is not the default, and it would happen
_after_ the pull is done.

The key difference here is that mercurial, thanks to its support of
anonymous branches can reliably represent what really happened (that
Alice's and Bob's histories diverged), while git cannot (since it
requires all branches to be linear).

There are solutions to this problem in git (e.g. Alice and Bob could
work on separate branches), but they are not as natural as in
mercurial (IMHO!).

2. The ui's. Git's UI is famous for being inconsistent
(www.youtube.com/watch?v=CDeG4S-mJts), while mercurial's is very
consistent, uniform and carefully designed. It is not perfect (nothing
is!) but it is much better.

3. Extensibility: Mercurial's hook and extension system is very
powerful and easy to use because it is all python based. To extend git
people usually write shell scripts on top of the "plumbing commands"
(or whatever they are called). I've been told (I have no direct
experience extending git) that it is not nearly as easy nor as nice to
do that as it is to extend mercurial (which I've done and is really
easy).

4. Mercurial tracks the "phase" of revisions. Mercurial keeps track of
which revisions have been "shared" (pulled or pushed) and (by default)
will not let you perform history editing operation ond shared
revisions. As far as I know git dot not have this concept, and thus is
happy to let you shoot yourself on the foot if you are not extremely
careful.

5. Mercurial is safe (append only) by default. This is something that
not everybody agrees, but I really like that mercurial does not enable
any of the unsafe history editing operations by default. To use them
you must manually enable their corresponding extensions (i.e. you must
confirm that you know what you are doing).

That is not to say that mercurial is better in all regards to git. Git
is a very nice and powerful tool. But where it matters mercurial is
better (IMHO) .

I hope these answer your question. I'm curious what problems did you
find on your own?

Cheers,

Angel