mercuria destroys everyone's work

[A. S. Budden]

On 14 January 2016 at 07:35, FLORENT Philippe <Philippe.FLORENT at edenred.com>
wrote:

> After a few months of usage, we thought we tamed the beast
>
> We thought installing our reps on a windows share had solved many issues
>
> Well, no we still loose code and hours of work
>
> countless hours repairing the new code that mercurial discarded in favour
> of older code without asking
>
> Countless hours repairing/recreating our repositories when they just crash
> for no reason, us unable to push our new commits
>
> We did not change the way we work with it, and after a month of
> “””correct””” behavior, the whole thing once again get completely messed up
>
> I officialy renounce, this package is an unstable and clearly not suited
> for a prod environement
>
>
I'm very surprised by this; we use this at my company in a production
environment with over 200 projects and a large number of developers.  We
chose Mercurial specifically because of previous history of having lost
work to Git's garbage collector and being very nervous about this - Git
seems to be designed with changing history being a normal, expected part of
the workflow.  Mercurial is far better for us because history is always
preserved and nothing is ever lost (unless you turn on some extensions and
use them).  After many years on many projects with many developers,
everyone is extremely happy with Mercurial and no work has ever been lost.

The only issues we have ever had were with failures to push due to the fact
we used to use a Windows share as our "server" and people with a *very*
slow internet connection (typically those based in India connected to a
server in the UK) would have periodic failures.  These never caused any
corruption on either end, but caused a lot of frustration.  We put this
down to Windows file shares being inherently poorly suited to slow internet
connections and since we've migrated everything to Rhodecode (which uses
http instead of Windows file shares) we've never had any further problems.

Al
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20160114/837488df/attachment.html>