hg copy -A and broken symlinks in Mercurial 1.4?

Matt Mackall mpm at selenic.com
Thu Sep 12 15:08:49 CDT 2013


On Thu, 2013-09-12 at 10:29 -0700, Dave Johansen wrote:
> On Thu, Sep 12, 2013 at 9:01 AM, Jordi Gutiérrez Hermoso
> <jordigh at octave.org> wrote:
> >
> > On Thu, 2013-09-12 at 08:08 -0700, Dave Johansen wrote:
> >
> > > Like mentioned, RHEL is a long term support release and people use
> > > it for the stability. They like the fact that they can still use the
> > > same predictable version of software instead of it changing
> > > underneath them every few weeks/months.
> >
> > We know what RHEL is like. And hg is one of the most stable pieces of
> > software out there ever. Mercurial's devotion to backwards
> > compatibility is incredible. Just backport a newer hg to RHEL
> > whatever. It's not difficult, and our local sysadmins here do it all
> > the time. If you need help, I can probably even provide you with the
> > relevant RPMs.
> >
> > Or you can refuse our long term support and just keep your very stable
> > bugs. Your choice.
> 
> I understand that and I'm not complaining about Mercurial. Yes, the
> compatibility of the interface is backwards compatible, but the issue
> is that the on disk format does change. So what happens when some guy
> accidentally does a commit on one of my machines with the newer
> version of Mercurial, but then still wants to use it on the machine
> with the vanilla install?

Absolutely fine, by design. It's absolutely fine for some users to be
using 0.9.5 and some to be using 2.7 and your servers to be on 1.4... In
fact, this will be vaguely like the situation of Mercurial's primary
audience: open source developers on the internet.

Various small details of the storage layout have changed over the years,
but -what's stored- hasn't changed since 0.5 or so. So ancient clients
can interoperate with new ones over the network and with existing repos
without trouble. 

The only time you _might_ get into trouble is if user A _creates_ a repo
with new version X, that user B with old version Y tries to access via
_shared disk_. In this case, simply downgrade the repo in question with
a network pull and move on. 

http://mercurial.selenic.com/wiki/UpgradingMercurial

Beyond that, if you're paying for RHEL, you're paying for support. None
of that money is coming to us to do continued maintenance of ancient
versions only RHEL users are still using. Have the folks at Red Hat sort
it out. But this is the fix you're looking for, according to bisect:

http://www.selenic.com/hg/rev/70236d6fd844

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list