Quantcast

Something wrong with selenic.com repos? abort: locking the remote repository failed

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Something wrong with selenic.com repos? abort: locking the remote repository failed

Greg Lindahl-6
[lindahl@greg-desk src]$ hg clone http://www.selenic.com/repo/hello my-hello
abort: locking the remote repository failed
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

queuebot
On Mon, 2010-03-08 at 19:17 -0800, Greg Lindahl wrote:
> [lindahl@greg-desk src]$ hg clone http://www.selenic.com/repo/hello my-hello
> abort: locking the remote repository failed

Interesting. You're attempting to do an --uncompressed clone (do you
have a default/alias set?) and the server doesn't have filesystem
permissions to lock its repos.

Looks like we should probably have a fall-back of some sort to normal
pull like we do when the server has uncompressed clone disabled.

--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Greg Lindahl-6
On Mon, Mar 08, 2010 at 11:35:12PM -0600, Matt Mackall wrote:

> Interesting. You're attempting to do an --uncompressed clone (do you
> have a default/alias set?)

Yes. I defaulted it that way because all my users are on fast links.
Then forgot when I went to clone from you.

-- greg


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Greg Lindahl-6
In reply to this post by queuebot
On Mon, Mar 08, 2010 at 11:35:12PM -0600, Matt Mackall wrote:

> Looks like we should probably have a fall-back of some sort to normal
> pull like we do when the server has uncompressed clone disabled.

Also, it would be nice to be able to do

hg clone --compressed

if I manage to remember that my default is uncompressed & I'm using
a slow link.

-- greg


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Adrian Buehlmann
On 10.03.2010 01:12, Greg Lindahl wrote:

> On Mon, Mar 08, 2010 at 11:35:12PM -0600, Matt Mackall wrote:
>
>> Looks like we should probably have a fall-back of some sort to normal
>> pull like we do when the server has uncompressed clone disabled.
>
> Also, it would be nice to be able to do
>
> hg clone --compressed
>
> if I manage to remember that my default is uncompressed & I'm using
> a slow link.

That's against:

http://www.selenic.com/mercurial/hgrc.5.html#defaults (quoting Matt):

"defaults are deprecated. Don't use them. Use aliases instead"

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Greg Lindahl-6
On Wed, Mar 10, 2010 at 01:38:37AM +0100, Adrian Buehlmann wrote:

> That's against:
>
> http://www.selenic.com/mercurial/hgrc.5.html#defaults (quoting Matt):
>
> "defaults are deprecated. Don't use them. Use aliases instead"

I also read:

  Note: It is possible to create aliases with the same names as existing
  commands, which will then override the original definitions. This is
  almost always a bad idea!

Are aliases with the same name as the command the right way to replace
defaults?

And if I have such an alias, won't I still need --compressed  to exist?

-- greg




_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Adrian Buehlmann
On 10.03.2010 01:52, Greg Lindahl wrote:

> On Wed, Mar 10, 2010 at 01:38:37AM +0100, Adrian Buehlmann wrote:
>
>> That's against:
>>
>> http://www.selenic.com/mercurial/hgrc.5.html#defaults (quoting Matt):
>>
>> "defaults are deprecated. Don't use them. Use aliases instead"
>
> I also read:
>
>   Note: It is possible to create aliases with the same names as existing
>   commands, which will then override the original definitions. This is
>   almost always a bad idea!

Right. So don't do it.

> Are aliases with the same name as the command the right way to replace
> defaults?

No. (nice try :-)


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Greg Lindahl-6
On Wed, Mar 10, 2010 at 02:39:33AM +0100, Adrian Buehlmann wrote:

> > Are aliases with the same name as the command the right way to replace
> > defaults?
>
> No. (nice try :-)

99.9% of the time my users want uncompressed clones and pulls. I'm not
supposed to change the default, and I'm not supposed to change how 'hg
clone' and 'hg pull' work... so I'm supposed to train all my users to
almost always use a different name, such as 'hg mercurial-is-hard-to-use-pull'
instead?

-- greg



_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Adrian Buehlmann
On 10.03.2010 02:59, Greg Lindahl wrote:

> On Wed, Mar 10, 2010 at 02:39:33AM +0100, Adrian Buehlmann wrote:
>
>>> Are aliases with the same name as the command the right way to replace
>>> defaults?
>>
>> No. (nice try :-)
>
> 99.9% of the time my users want uncompressed clones and pulls. I'm not
> supposed to change the default, and I'm not supposed to change how 'hg
> clone' and 'hg pull' work... so I'm supposed to train all my users to
> almost always use a different name, such as 'hg mercurial-is-hard-to-use-pull'
> instead?

What does this have to do with pull? pull doesn't have an --uncompressed
option. Only clone does.

It seems like you currently have no other option than defining a nice
short alias like 'cloneuc' for 'clone --uncompressed' (given you don't
want to have to use 'clone --uncompressed'), if you want to comply with
the deprecation. Doing this has the benefit that you still have the
original behavior of 'clone' available for the other cases you say you
need it.

The alternative is to ignore the deprecation (like many users do, I
guess - intentionally or not), but then it is rather unlikely that Matt
will accept a patch for a new --compressed option, as you proposed, by
citing that you need it precisely because you continue to use a feature
that Matt explicitly deprecated.

FWIW, the deprecation makes quite sense to me. Your request for a
--compressed option is a textbook example why option defaults are bad
(see also [1], and especially [2]).

Again, the best thing to do is define some new nice short alias like
'cloneuc' for 'clone --uncompressed', instead of insisting to hijack the
standard clone command "for almost all the time but then please
implement a new --compressed option for us, so we can override the
hijacking back sometimes if we want the original clone".

You then can use 'clone' instead of your new proposed 'clone
--compressed'. Which I doubt that you really want to use - compare with
your 'hg mercurial-is-hard-to-use-xxx' argument.

If we would indeed go implement your --compressed proposal, we would
have to implement an --anti-option-xx for every single --option-xx of
mercurial, because someone could have set it in his defaults. A rather
pointless endeavor.

[1] http://selenic.com/repo/hg/rev/24dad078603b
[2] http://selenic.com/pipermail/mercurial-devel/2009-October/016095.html
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Sune Foldager
In reply to this post by Greg Lindahl-6
Just to show some support, we also use 'defaults' extensively at work,
and can't do without them in our environment. If there were removed,
it's likely we would patch them back in in local queue :-/.

In a large-ish corporate environments, many developers don't know and
don't care about version control, and we need to go a long way towards
making it as easy and simple as possible, or else WE get the support
burden when they call us.

/Sune
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Christian Ebert
In reply to this post by Adrian Buehlmann
* Adrian Buehlmann on Wednesday, March 10, 2010 at 09:51:26 +0100

> On 10.03.2010 02:59, Greg Lindahl wrote:
>> On Wed, Mar 10, 2010 at 02:39:33AM +0100, Adrian Buehlmann wrote:
>>
>>>> Are aliases with the same name as the command the right way to replace
>>>> defaults?
>>>
>>> No. (nice try :-)
>>
>> 99.9% of the time my users want uncompressed clones and pulls. I'm not
>> supposed to change the default, and I'm not supposed to change how 'hg
>> clone' and 'hg pull' work... so I'm supposed to train all my users to
>> almost always use a different name, such as 'hg mercurial-is-hard-to-use-pull'
>> instead?
>
> What does this have to do with pull? pull doesn't have an --uncompressed
> option. Only clone does.
>
> It seems like you currently have no other option than defining a nice
> short alias like 'cloneuc' for 'clone --uncompressed' (given you don't
> want to have to use 'clone --uncompressed'), if you want to comply with
> the deprecation. Doing this has the benefit that you still have the
> original behavior of 'clone' available for the other cases you say you
> need it.
>
> The alternative is to ignore the deprecation (like many users do, I
> guess - intentionally or not), but then it is rather unlikely that Matt
> will accept a patch for a new --compressed option, as you proposed, by
> citing that you need it precisely because you continue to use a feature
> that Matt explicitly deprecated.
>
> FWIW, the deprecation makes quite sense to me. Your request for a
> --compressed option is a textbook example why option defaults are bad
> (see also [1], and especially [2]).

One could argue that

[diff]
git = True

is a [defaults] that sneaked in by the backdoor, even for several
commands (export, email etc.). I can unset it with hg --config
diff.git=False diff; however, I cannot define an alias for the
latter, --config being a global option. So I have to go "the
other way round":

[diff]

[alias]
gdiff = diff --git

> Again, the best thing to do is define some new nice short alias like
> 'cloneuc' for 'clone --uncompressed', instead of insisting to hijack the
> standard clone command "for almost all the time but then please
> implement a new --compressed option for us, so we can override the
> hijacking back sometimes if we want the original clone".
>
> You then can use 'clone' instead of your new proposed 'clone
> --compressed'. Which I doubt that you really want to use - compare with
> your 'hg mercurial-is-hard-to-use-xxx' argument.
>
> If we would indeed go implement your --compressed proposal, we would
> have to implement an --anti-option-xx for every single --option-xx of
> mercurial, because someone could have set it in his defaults. A rather
> pointless endeavor.
>
> [1] http://selenic.com/repo/hg/rev/24dad078603b
> [2] http://selenic.com/pipermail/mercurial-devel/2009-October/016095.html

c
--
theatre - books - texts - movies
Black Trash Productions at home: <http://www.blacktrash.org/>
Black Trash Productions on Facebook:
<http://www.facebook.com/pages/Black-Trash-Productions/277569157339>
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Adrian Buehlmann
In reply to this post by Sune Foldager
On 10.03.2010 11:13, Sune Foldager wrote:
> Just to show some support, we also use 'defaults' extensively at work,
> and can't do without them in our environment. If there were removed,
> it's likely we would patch them back in in local queue :-/.
>
> In a large-ish corporate environments, many developers don't know and
> don't care about version control, and we need to go a long way towards
> making it as easy and simple as possible, or else WE get the support
> burden when they call us.

The "corporate environment" argument is a red herring here.

If these users are dumb enough so that they don't know how to edit their
Mercurial.ini, then this strategy might actually work.

But then, editing your fine tuned [defaults] by users is probably no
longer supported by your "support".

Otherwise, how do you know what the default for option x for user y is
when y calls you and tells you that clone failed?

But if you have such a locked-down environment, you might as well define
your private tailored locked-down command set with an extension everyone
has to use in your shop (instead of abusing defaults).
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Sune Foldager
On 10-03-2010 11:56, Adrian Buehlmann wrote:
> The "corporate environment" argument is a red herring here.

Hardly... it's a reality some of us has to face.

> If these users are dumb enough so that they don't know how to edit their
> Mercurial.ini, then this strategy might actually work.

Nice... our users aren't dumb, just not interested in this.

> But then, editing your fine tuned [defaults] by users is probably no
> longer supported by your "support".
>
> Otherwise, how do you know what the default for option x for user y is
> when y calls you and tells you that clone failed?

They don't change their defaults. Most of them don't know they exist,
because they are not interested in Mercurial.

> But if you have such a locked-down environment, you might as well define
> your private tailored locked-down command set with an extension everyone
> has to use in your shop (instead of abusing defaults).

Calm down :-). I am not abusing anything, I am exploiting a feature
which happens to be supported. I don't want to lock down anything, as we
do have (few) expert users who are interested in being able to tweak
these things, among others.

/Sune
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Adrian Buehlmann
On 10.03.2010 12:05, Sune Foldager wrote:
> On 10-03-2010 11:56, Adrian Buehlmann wrote:
>> The "corporate environment" argument is a red herring here.
>
> Hardly... it's a reality some of us has to face.

Sure, no one really doubts that you are working in a corporate
environment :-)

But telling us that option defaults are *needed* or should be provided
for users in "corporate environments" is the red herring here.

I would rather say that in your "corporate environment" you have
effectively removed the [defaults] feature for users, since your
standard users are not supposed to edit [defaults].

>> If these users are dumb enough so that they don't know how to edit their
>> Mercurial.ini, then this strategy might actually work.
>
> Nice... our users aren't dumb, just not interested in this.

I guess they might be interested in this, as soon as some of them have
"wrong" things in their [defaults]. Breaking whatever scripts or
commands they happen to use at the moment.

>> But then, editing your fine tuned [defaults] by users is probably no
>> longer supported by your "support".
>>
>> Otherwise, how do you know what the default for option x for user y is
>> when y calls you and tells you that clone failed?
>
> They don't change their defaults. Most of them don't know they exist,
> because they are not interested in Mercurial.

>> But if you have such a locked-down environment, you might as well define
>> your private tailored locked-down command set with an extension everyone
>> has to use in your shop (instead of abusing defaults).
>
> Calm down :-). I am not abusing anything, I am exploiting a feature
> which happens to be supported. I don't want to lock down anything, as we
> do have (few) expert users who are interested in being able to tweak
> these things, among others.

Which still doesn't address the point about having users with
disagreeing/strange option defaults, calling support and then "support"
first needs to find out what the heck they have in their [defaults] in
order to being able to help them with their command use case.

Or random scripts breaking because a command has a surprising
back-firing non-standard default for an option.

This is a reality for supporters supporting not just a single big
uniform "corporate environment" of users who don't even know what "SCM"
means.

IMHO, Matt's decision to deprecate [defaults] is sound. But of course
everyone is free to have a private patch queue that modifies mercurial
for their "corporate environment" in case [defaults] will be removed in
a future version. But I'm not sure anyone here really cares much about
such private patch queues.

Folks, it is unlikely that Matt will ever take a --compressed option
patch. So, I suggest we move on and do something more interesting instead.
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Sune Foldager
On 10-03-2010 13:29, Adrian Buehlmann wrote:
> On 10.03.2010 12:05, Sune Foldager wrote:
>> On 10-03-2010 11:56, Adrian Buehlmann wrote:
>>> The "corporate environment" argument is a red herring here.
>>
>> Hardly... it's a reality some of us has to face.
>
> Sure, no one really doubts that you are working in a corporate
> environment :-)

...

> But telling us that option defaults are *needed* or should be provided
> for users in "corporate environments" is the red herring here.

*I* think the feature is useful, and it is quite needed for us, which is
what I said. I then made a point about its possible use in a corporate
environment, which seemed similar to the poster. You may have a
different opinion, which is fine, but I can argue whatever I want.

> IMHO, Matt's decision to deprecate [defaults] is sound. But of course
> everyone is free to have a private patch queue that modifies mercurial
> for their "corporate environment" in case [defaults] will be removed in
> a future version.

Thanks.

> But I'm not sure anyone here really cares much about such private patch queues.

Yeah, well I am not very bothered by what you "are sure" of. If *you*
don't care about it, then don't reply to the mail!
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Greg Lindahl-6
In reply to this post by Adrian Buehlmann
On Wed, Mar 10, 2010 at 09:51:26AM +0100, Adrian Buehlmann wrote:

> It seems like you currently have no other option than defining a nice
> short alias like 'cloneuc' for 'clone --uncompressed' (given you don't
> want to have to use 'clone --uncompressed'), if you want to comply with
> the deprecation.

Which isn't user-friendly, as my joke example showed.

Let me give you a better poster child:

We found that our users were frequently, accidentally committing
unrelated, forgotten changes.

We asked them to use "hg diff" or "hg st" before committing. That only
slightly reduced the error rate.

Next, we urged people to use "hg commit -v", but they didn't remember
and the error rate stayed high.

Finally, we made "hg commit -v" the default, and now only our CEO
screws up.

It boggles the mind that making diff --git the default is easy because
that's "[diff] git = True" instead of "[default] ..." but that the easy
way to make other small tweaks is deprecated.

-- greg


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Steve Borho
On Wed, Mar 10, 2010 at 1:16 PM, Greg Lindahl <[hidden email]> wrote:

> On Wed, Mar 10, 2010 at 09:51:26AM +0100, Adrian Buehlmann wrote:
>
>> It seems like you currently have no other option than defining a nice
>> short alias like 'cloneuc' for 'clone --uncompressed' (given you don't
>> want to have to use 'clone --uncompressed'), if you want to comply with
>> the deprecation.
>
> Which isn't user-friendly, as my joke example showed.
>
> Let me give you a better poster child:
>
> We found that our users were frequently, accidentally committing
> unrelated, forgotten changes.
>
> We asked them to use "hg diff" or "hg st" before committing. That only
> slightly reduced the error rate.
>
> Next, we urged people to use "hg commit -v", but they didn't remember
> and the error rate stayed high.
>
> Finally, we made "hg commit -v" the default, and now only our CEO
> screws up.

"hgtk ci" would probably fix that even more :)

Cheers,

--
Steve Borho
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Martin Geisler
In reply to this post by Sune Foldager
Sune Foldager <[hidden email]> writes:

> On 10-03-2010 13:29, Adrian Buehlmann wrote:
>
>> But telling us that option defaults are *needed* or should be
>> provided for users in "corporate environments" is the red herring
>> here.
>
> *I* think the feature is useful, and it is quite needed for us, which
> is what I said. I then made a point about its possible use in a
> corporate environment, which seemed similar to the poster.

I also find defaults very useful, despite being only myself. I wont make
new aliases for core commands -- I want to use the core command names,
but with extra bells and whistles as I see fit. Specifically, I have
these defaults:

  [defaults]
  diff = --color=always
  qdiff = --color=always

They force color output, even when piping to less or similar.

Now that we have the HGPLAIN environment variable, I think we should
de-deprecate the defaults section. Scripts and front-ends that rely on
parsing command line output should set this variable.

--
Martin Geisler

Fast and powerful revision control: http://mercurial.selenic.com/

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Adrian Buehlmann
On 11.03.2010 00:46, Martin Geisler wrote:

> Sune Foldager <[hidden email]> writes:
>
>> On 10-03-2010 13:29, Adrian Buehlmann wrote:
>>
>>> But telling us that option defaults are *needed* or should be
>>> provided for users in "corporate environments" is the red herring
>>> here.
>>
>> *I* think the feature is useful, and it is quite needed for us, which
>> is what I said. I then made a point about its possible use in a
>> corporate environment, which seemed similar to the poster.
>
> I also find defaults very useful, despite being only myself. I wont make
> new aliases for core commands -- I want to use the core command names,
> but with extra bells and whistles as I see fit. Specifically, I have
> these defaults:
>
>   [defaults]
>   diff = --color=always
>   qdiff = --color=always

These kind of defaults seem rather harmless to me. But there are
others, that are not. Imagine a --clean as default for update in
[defaults]: admittedly a bit a contrived example, but it's still
possible to construct some not so nice traps with [defaults].

> They force color output, even when piping to less or similar.
>
> Now that we have the HGPLAIN environment variable, I think we should
> de-deprecate the defaults section. Scripts and front-ends that rely on
> parsing command line output should set this variable.

But how does this play with Greg Lindahl's example of '--uncompressed'
for clone in [defaults]?

Do you want to add a new --compressed option, in order for users to be
able to override an --uncompressed in [defaults] (like Greg asked for)?
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Something wrong with selenic.com repos? abort: locking the remote repository failed

Martin Geisler
Adrian Buehlmann <[hidden email]> writes:

> On 11.03.2010 00:46, Martin Geisler wrote:
>>
>> I also find defaults very useful, despite being only myself. I wont
>> make new aliases for core commands -- I want to use the core command
>> names, but with extra bells and whistles as I see fit. Specifically,
>> I have these defaults:
>>
>>   [defaults]
>>   diff = --color=always
>>   qdiff = --color=always
>
> These kind of defaults seem rather harmless to me. But there are
> others, that are not. Imagine a --clean as default for update in
> [defaults]: admittedly a bit a contrived example, but it's still
> possible to construct some not so nice traps with [defaults].
I agree, people can mess up with defaults. But I don't think we can
deduce the "right" and the "wrong" uses of defaults up front. The users
will have to learn that the hard way.

>> They force color output, even when piping to less or similar.
>>
>> Now that we have the HGPLAIN environment variable, I think we should
>> de-deprecate the defaults section. Scripts and front-ends that rely
>> on parsing command line output should set this variable.
>
> But how does this play with Greg Lindahl's example of '--uncompressed'
> for clone in [defaults]?
>
> Do you want to add a new --compressed option, in order for users to be
> able to override an --uncompressed in [defaults] (like Greg asked
> for)?
I don't think we want two options for each Boolean flag. We should
instead add some cleverness to so that

  --foo

means

  --foo=yes

and

  --foo=no

is a way to unset the "foo" flag (ui.configbool should be used to
interpret more values at True and False). The --color flag already has
this kind of logic (though I don't like the "always" and "never" labels
for True and False).

--
Martin Geisler

Fast and powerful revision control: http://mercurial.selenic.com/

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial

attachment0 (203 bytes) Download Attachment
12
Loading...