hg copy -A and broken symlinks in Mercurial 1.4?

[Dave Johansen]

On Thu, Sep 12, 2013 at 1:08 PM, Matt Mackall <mpm at selenic.com> wrote:
> 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

http://mercurial.selenic.com/wiki/UpgradingMercurial#Multiple_client_versions_on_a_shared_disk
http://mercurial.selenic.com/wiki/RequiresFile

I thought that I had run into a scenario where a newer version had
added one of the requires flags to a shared disk repo, but maybe I'm
remembering incorrectly or something else was actually the cause of my
issue. If it really is the case that newer versions won't do that sort
of thing, then yes, multiple versions could coexist on a network using
a shared disk.

> 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

I think that my original question may have been misunderstood. My
point wasn't to complain about Mercurial, ask for "long term support",
or anything of the sort. I just wanted to be able to submit a patch
(because it helps get the fix integrated into the official release a
LOT faster) and hoped for feedback/help on this list to make sure that
the fix I did was correct/complete. I understand that upgrading to a
newer version of Mercurial is a valid option, but that doesn't mean
getting bug fixes in an older version shouldn't be. I'm just trying to
help enable a bug fix in an old version (with some help from the
experts), not ask someone to do it for me.

Thank you for the help and the link to the changeset was especially helpful,
Dave