0.9 coming soon!

[Brendan Cully]

On Thursday, 27 April 2006 at 03:55, Vincent Danjean wrote:
>   The last two one are needed if we want to use mercurial with the hglib
> backend of tailor. This backend, wrote in python, calls directly the
> internal of mercurial. I am not enough skilled in python to know why,
> but with these patch mercurial function have a wrong behaviour. My
> understanding is that tailor is stricter than mercurial for its code.
> But I do not know where to look for seeing this set up.
> 
> submitted_upstream__hash_keys.patch is needed because using a non
> existant key in a hash return an error instead of a 'false' value.

This is probably just as easy to fix in tailor.

> submitted_upstream__dirstate_is_not_in_unicode.patch is needed because
> without it (ie when using a '+' operator on the string) a Unicode
> exception occurs (ie the string is not a valid unicode one). I do not
> know how to tell python that these string (e and f) are binary strings
> and not unicode strings.

This should be fixed in tailor too (if it hasn't yet been - I thought
I'd done a bunch of unicode fixes a few weeks ago).

>   And there is still one 'bug' when using mercurial with hglib backend
> of tailor. When pulling a null repo (see my previous example in this
> mail), hg works because the high level program catch a exception and
> rollback a transaction:
> vdanjean at cayuga:/tmp/b$ hg pull ../a
> pulling from ../a
> requesting all changes
> adding changesets
> abort: group to be added is empty!
> transaction abort!
> rollback completed
> vdanjean at cayuga:/tmp/b$
>   When tailor directly calls hg.pull(...), it gets the exception and
> die. Would not it be better if the exception were caught in the
> hg.pull() method instead of commands.dispatch / transaction.py ?
> Why is it necessary to generate such an exception when there is nothing
> to pull ?

I'm not sure about this either, but I'm guessing that as with the
above fixes this could also simply be trapped in tailor. I believe
there may be some kind of end-to-end principle at work here, that
error handling should be done as late as possible for efficiency and
because the points closest to the user know best how to handle errors.