This is a repost from a posting I sent last August. One of the issues
(the hg-eol extension) is largely resolved, so I'm only asking for
help on the other issue.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
d
Paul Moore writes:
> The result is that user workspaces *may* (quite probably, will)
> contain files with a mixture of line endings if care is not taken.
Yes. Under your "fixed-EOL-files-are-binary" scheme, this is
guaranteed for Unix systems.
> As regards (1), I assume that for "text" files
Dirkjan Ochtman writes:
> On 05/09/2009 16:59, Stephen J. Turnbull wrote:
> > git has a nice filter-branch command, which would allow you to
> > automatically repair the problem (it works basically by checking out
> > each changeset and rerecording it with the appropriate commands). I
> > kno
Paul Moore:
> 1. Given that the "problematic" tools (notepad and Visual Studio) are
> Windows tools, we seem to be back to the idea that this extension is
> only needed by Windows developers. As I understood the consensus to be
> that the extension should be for all users, I suspect I've missed
>
Dirkjan Ochtman:
> I know a lot of projects use Mercurial on Windows as well, I'm not
> aware of any big problems with it.
If you have a Windows-only project with CRLF files using Mercurial
then there is no line end problem as Mercurial preserves the CRLFs for
you. Line end problems occur on m
"Martin v. Löwis" writes:
>>> I don't think this problem is really serious. If the push fails, you
>>> can just commit (locally) a new changeset that repairs the EOL or
>>> indentation problems, and push the whole bunch of changesets again
>>> (I assume the server-side hook will not examine chang
On 05/09/2009, "Martin v. Löwis" wrote:
>
> Creating the clone. ISTM that it leaves the http connection open while
> doing stuff locally (or creates multiple of them, and one times out).
>
> It starts cloning, and then, after an hour or so, it reports ABORT,
> and rolls back, for no apparent reaso
>> 2. Allowing text files to be checked out in whatever form the user
>> prefers seems complicated. The alternative would likely be to say test
>> files are checked out in "native" form. That works, but would irritate
>> me as I work on Windows, but prefer strongly to use LF line endings
>> (yes, I
> There are 2 separate questions - (1) what is held in the repository,
> and (2) what is in the user's workspace. The two clearly interact.
[...]
> As regards (1), I assume that for "text" files, a consistent EOL
> convention (assumed LF) should be used in the repository.
Correct. I believe Martin
> I know a lot of projects use Mercurial on Windows as well, I'm not
> aware of any big problems with it.
I trust that indeed, there are no big problems for most users. I
also trust that the hg developers are, in general, open to incorporating
improvements on Windows.
I'm still skeptical though w
2009/9/5 "Martin v. Löwis" :
>> FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad
>> requires /r/n, but do IDLE and other editors (on Windows) that people
>> would actually use to create/edit such files? I would personally be
>> willing to install a notepad replacement if need
On Sat, Sep 5, 2009 at 18:25, "Martin v. Löwis" wrote:
> I think that's the case. It's pretty much a Unix-only tool, like most of
> the other DVCS implementations.
I know a lot of projects use Mercurial on Windows as well, I'm not
aware of any big problems with it.
> FWIW, I tried to check out Mo
Martin v. Löwis schrieb:
>> I don't think this problem is really serious.
>> If the push fails, you can just commit (locally) a new changeset that
>> repairs the EOL or indentation problems
>
> I would find that unfortunate. It's a fairly irrelevant change, yet
> it may manage to corrupt the histo
On 05/09/2009 18:28, "Martin v. Löwis" wrote:
I would be in favor (although, IIUC, "mandate" here would be a
social thing, not a technical one).
Right, but that would be the same for the extension.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-
>> But it shouldn't happen often that the server refuses a push;
>> all errors should already be caught on the clients.
>
> We could just mandate the same hook code as a commit hook.
I would be in favor (although, IIUC, "mandate" here would be a
social thing, not a technical one).
Regards,
Marti
> FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad
> requires /r/n, but do IDLE and other editors (on Windows) that people
> would actually use to create/edit such files? I would personally be
> willing to install a notepad replacement if needed to quickview such files.
Visu
On Sat, Sep 5, 2009 at 18:18, "Martin v. Löwis" wrote:
> But it shouldn't happen often that the server refuses a push;
> all errors should already be caught on the clients.
We could just mandate the same hook code as a commit hook.
Cheers,
Dirkjan
___
>> I don't think this problem is really serious. If the push fails, you
>> can just commit (locally) a new changeset that repairs the EOL or
>> indentation problems, and push the whole bunch of changesets again (I
>> assume the server-side hook will not examine changesets individually,
>> but only
> I don't think this problem is really serious.
> If the push fails, you can just commit (locally) a new changeset that
> repairs the EOL or indentation problems
I would find that unfortunate. It's a fairly irrelevant change, yet
it may manage to corrupt the history (hg blame).
> and push the who
On 05/09/2009 16:59, Stephen J. Turnbull wrote:
git has a nice filter-branch command, which would allow you to
automatically repair the problem (it works basically by checking out
each changeset and rerecording it with the appropriate commands). I
know bzr is growing something similar, so presum
On 05/09/2009 17:09, Antoine Pitrou wrote:
Mercurial is used by e.g. Mozilla, which is not really known for poor Windows
support (chances are many Firefox developers are Windows-based). I wonder
whether they have written their own extension, or if they simply rely on their
text editors to do the
On 05/09/2009, Antoine Pitrou wrote:
> Terry Reedy udel.edu> writes:
>>
>> If essentially all text files need fixed line endings on Windows, then
>> hg really needs this built in. Has it really not been used much on
>> Windows?
>
> Mercurial is used by e.g. Mozilla, which is not really known for
Terry Reedy udel.edu> writes:
>
> If essentially all text files need fixed line endings on Windows, then
> hg really needs this built in. Has it really not been used much on Windows?
Mercurial is used by e.g. Mozilla, which is not really known for poor Windows
support (chances are many Firefox
Antoine Pitrou writes:
> Le samedi 05 septembre 2009 à 15:19 +0200, "Martin v. Löwis" a écrit :
>
>> In addition, a DVCS brings in another problem dimension: when people
>> push their changes, they have *already* committed them - and perhaps
>> not even they, but a contributor from which they had
Martin v. Löwis wrote:
I'm starting to wonder what the problem really is that makes it so
Python-specific. If I understood correctly, it's about a couple of files which
must be stored using non-Unix line endings, right? (in the PC and PCbuild
directories?)
No. It's about files that must, when c
Antoine Pitrou writes:
> > In addition, a DVCS brings in another problem dimension: when people
> > push their changes, they have *already* committed them - and perhaps not
> > even they, but a contributor from which they had been pulling changes.
> > The bogus change may have been weeks ago,
Le samedi 05 septembre 2009 à 15:19 +0200, "Martin v. Löwis" a écrit :
> No. It's about files that must, when checked out on Windows, have CRLF
> endings, and, when checked out on Unix, have LF endings - i.e. all the
> ..py, .c, .h, and .rst files, plus a couple of others which don't require
> spec
> I'm starting to wonder what the problem really is that makes it so
> Python-specific. If I understood correctly, it's about a couple of files which
> must be stored using non-Unix line endings, right? (in the PC and PCbuild
> directories?)
No. It's about files that must, when checked out on Wind
Mark Hammond gmail.com> writes:
>
> What is the hope of an EOL extension which meets our requirements coming
> directly out of the hg community? If that hope is small, where does
> that leave us?
I'm starting to wonder what the problem really is that makes it so
Python-specific. If I understo
2009/9/5 "Martin v. Löwis" :
>> What is the hope of an EOL extension which meets our requirements coming
>> directly out of the hg community? If that hope is small, where does
>> that leave us?
>
> As before. I'll repost my request for help, and we stay with subversion
> meanwhile.
>
> Perhaps I'l
> What is the hope of an EOL extension which meets our requirements coming
> directly out of the hg community? If that hope is small, where does
> that leave us?
As before. I'll repost my request for help, and we stay with subversion
meanwhile.
Perhaps I'll post it to some mercurial list as well
On 30/08/2009 9:37 PM, Martin Geisler wrote:
Mark Hammond writes:
1) I've stalled on the 'none:' patch I promised to resurrect. While
doing this, I re-discovered that the tests for win32text appear to
check win32 line endings are used by win32text on *all* platforms, not
just Windows.
I thi
"Martin v. Löwis" writes:
>> So the extension should do that: either abort commits with the wrong
>> EOL markers or do as Subversion and automatically convert the file in
>> the working copy.
>
> Maybe I misunderstand: when people use the extension, they cannot
> possibly make mistakes, right? Be
> I suggested a new extension for two reasons:
>
> * I'm using Linux, and I mentally skip over all extensions that mention
> "win32"... I guess others do the same, and in this case it's really a
> shame since converting EOL markers is a cross-platform problem: if
> someone creates a reposito
Mark Hammond writes:
> 1) I've stalled on the 'none:' patch I promised to resurrect. While
> doing this, I re-discovered that the tests for win32text appear to
> check win32 line endings are used by win32text on *all* platforms, not
> just Windows.
I think it is only Patrick Mezard who knows ho
On 18/08/2009 6:20 PM, Dirkjan Ochtman wrote:
On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote:
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
I think the most important item here is currentl
Mark Hammond wrote:
> On 23/08/2009 5:25 PM, "Martin v. Löwis" wrote:
>>> If this becomes seen as 'my' cause, I suspect it will run out of steam
>>> very quickly. I truly hope python-dev, as a community, takes some
>>> ownership of this issue
>>
>> That certainly won't happen. python-dev, as a com
On 23/08/2009 5:25 PM, "Martin v. Löwis" wrote:
If this becomes seen as 'my' cause, I suspect it will run out of steam
very quickly. I truly hope python-dev, as a community, takes some
ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken ownersh
> If this becomes seen as 'my' cause, I suspect it will run out of steam
> very quickly. I truly hope python-dev, as a community, takes some
> ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken ownership of anything. It's always individuals who t
>>> From my POV, this would be required in some form or another before such
>>> a scheme could actually work. Without it we end up with an improved
>>> win32text (good!)
>>
>> I still think this would be actually bad.
>>
>> Instead, a new extension should be written, with a name that does not
>>
On 22/08/2009 7:09 PM, "Martin v. Löwis" wrote:
From my POV, this would be required in some form or another before such
a scheme could actually work. Without it we end up with an improved
win32text (good!)
I still think this would be actually bad.
Instead, a new extension should be written,
On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
> Possibly - although I would expect the existing section names be reused
> when applied to a versioned file, I'd be more than happy for the hg guys
> to declare
On Fri, Aug 21, 2009 at 6:58 PM, Mark Hammond wrote:
> [encode]
> *.dsp=none:
> **=cleverencode:
>
> The end result should be that anything with 'none:' forms what you call an
> ignore list.
>
> Would that not meet your requirements?
It would, so I guess I'll hold off on digging into the hook cod
Stephen J. Turnbull wrote:
> Dirkjan Ochtman writes:
>
> > [Clients] cannot be trusted (e.g. I might put a win32text stub in
> > there somewhere that does nothing).
>
> Heck, just edit the .hgrules file, and do a Houdini on any and all
> handcuffs.
>
> Don't trust software, trust people -- but
Paul Moore writes:
> 2009/8/22 Martin Geisler :
>> Oh, we try to be very paranoid in Mercurial :-) That's why you don't
>> see any support for copying hgrc files when you clone and why hg wont
>> trust hgrc files not owned by you: it should be safe to do
>>
>> cd ~collegue/src/python
>> hg tip
2009/8/22 Martin Geisler :
> Oh, we try to be very paranoid in Mercurial :-) That's why you don't see
> any support for copying hgrc files when you clone and why hg wont trust
> hgrc files not owned by you: it should be safe to do
>
> cd ~collegue/src/python
> hg tip
So, is the implication there
"Stephen J. Turnbull" writes:
> Mark Hammond writes:
> > On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
>
> > Possibly - although I would expect the existing section names be reused
> > when applied to a versioned file, I'd be more than happy for the hg guys
> > to declare new names are
"Stephen J. Turnbull" writes:
> Mark Hammond writes:
>
> [extensions]
> required_for_commit = win32text,some_other_ext
>
> That might require a change to hg's ini file semantics if currently it
> refuses to parse [extension] sections in versioned hgrcs.
It doesn' refuse anything like that. When
> From my POV, this would be required in some form or another before such
> a scheme could actually work. Without it we end up with an improved
> win32text (good!)
I still think this would be actually bad.
Instead, a new extension should be written, with a name that does not
have "win32" as a su
Dirkjan Ochtman writes:
> [Clients] cannot be trusted (e.g. I might put a win32text stub in
> there somewhere that does nothing).
Heck, just edit the .hgrules file, and do a Houdini on any and all
handcuffs.
Don't trust software, trust people -- but help them avoid thoughtless
mistakes.
__
Mark Hammond writes:
> On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
> Possibly - although I would expect the existing section names be reused
> when applied to a versioned file, I'd be more than happy for the hg guys
> to declare new names are appropriate for this.
If there's already a
On Sat, Aug 22, 2009 at 01:17, Martin Geisler wrote:
> In the general case, you can specify an extension to be enabled by
> filename:
>
> [extensions]
> foo = ~/src/foo
>
> So if I can enable an extension like that on your system, I might be
> evil and commit a bad extension *and* enable it at th
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
Indeed.
> [config] # or maybe [rules] ?
> required_extensions = win32text, some_pydev_specific_extension
[extensions]
required_for_com
Mark Hammond writes:
> Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
> [config] # or maybe [rules] ?
> required_extensions = win32text, some_pydev_specific_extension
[extensions]
required_for_commit = win32text,some_other_ext
That might require a change to hg's i
On 22/08/2009 12:10 AM, Dj Gilcrease wrote:
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammond wrote:
Maybe you can enumerate what you think needs to change in mercurial, then
once we have a plan in place it will be clearer who can do what.
The encode/decode hooks need to be passed the filename th
On 22/08/2009 12:19 AM, Dirkjan Ochtman wrote:
On Fri, Aug 21, 2009 at 16:10, Dj Gilcrease wrote:
I like this, though maybe .hgextensions since it would contain
versioned rules and the actual required extension. The extra sub
directories are not really required IMHO, you just have a hgrc file
t
Dj Gilcrease writes:
> On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtman wrote:
>> Enabling extensions in a versioned file is not going to fly.
>
> any specific reason?
In the general case, you can specify an extension to be enabled by
filename:
[extensions]
foo = ~/src/foo
So if I can enab
On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtman wrote:
> Enabling extensions in a versioned file is not going to fly.
any specific reason?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Fri, Aug 21, 2009 at 16:10, Dj Gilcrease wrote:
> I like this, though maybe .hgextensions since it would contain
> versioned rules and the actual required extension. The extra sub
> directories are not really required IMHO, you just have a hgrc file
> that works the same as the local hgrc file e
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammond wrote:
> Maybe you can enumerate what you think needs to change in mercurial, then
> once we have a plan in place it will be clearer who can do what.
The encode/decode hooks need to be passed the filename they are
working on so you can have an ignore l
Nick Coghlan writes:
> Stephen J. Turnbull wrote:
> > Note that Bazaar is currently discussing some similar policies. I
> > think the name they have settled on is ".bzrrules". Maybe .hgrules is
> > a better name.
>
> So it would be .hgrules/? With the extension then
> defining the content
Stephen J. Turnbull wrote:
> Note that Bazaar is currently discussing some similar policies. I
> think the name they have settled on is ".bzrrules". Maybe .hgrules is
> a better name.
So it would be .hgrules/? With the extension then
defining the contents of the rule file?
An alternative would
Mark Hammond writes:
> * Add support for versioned 'filter rules' - eg, /.hgfilters or similar.
>
> * This might be pushing my luck, but: add 'defensive' support to core hg
> for this feature - if /.hgfilters exists, hg should refuse to operate on
> the working tree unless the win32text ex
On Fri, Aug 21, 2009 at 09:16, Mark Hammond wrote:
> I'm resurrecting my patch to support a filter called 'none' (which is
> turning out to be harder than I thought). Off the top of my head, it would
> the following would give us a pretty solid solution:
>
> * Finish my patch for 'none' as a filte
[Adjusted the CCs...]
On 19/08/2009 8:21 AM, Dj Gilcrease wrote:
On Tue, Aug 18, 2009 at 2:12 AM, "Martin v. Löwis" wrote:
The second item is line conversion hooks. Dj Gilcrease has posted a
solution which he considers a hack himself. Mark Hammond has also
volunteered, but it seems some volunt
On Tue, Aug 18, 2009 at 2:12 AM, "Martin v. Löwis" wrote:
> The second item is line conversion hooks. Dj Gilcrease has posted a
> solution which he considers a hack himself. Mark Hammond has also
> volunteered, but it seems some volunteer needs to be "in charge",
> keeping track of a proposed solut
On Tue, Aug 18, 2009 at 21:46, Brett Cannon wrote:
> Can we possibly get these todo items in the PEP? I keep looking at the
> PEP out of habit to see what the blockers are and they are not there,
> at which point I have to dig up Martin's email.
Will do.
Cheers,
Dirkjan
_
[stripping out python-list and Mark from the CC]
On Tue, Aug 18, 2009 at 01:20, Dirkjan Ochtman wrote:
> On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote:
>> In this thread, I'd like to collect things that ought to be done
>> but where Dirkjan has indicated that he would prefer if somebody e
On Tue, Aug 18, 2009 at 13:32, Mark Hammond wrote:
> I can make time, somewhat spasmodically, starting fairly soon. Might I
> suggest that as a first task I can resurrect my old stale patch, and you can
> arrange to install win32text locally and start experimenting with how mixed
> line-endings ca
On 18/08/2009 6:20 PM, Dirkjan Ochtman wrote:
On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote:
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
I think the most important item here is currentl
On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote:
> In this thread, I'd like to collect things that ought to be done
> but where Dirkjan has indicated that he would prefer if somebody else
> did it.
I think the most important item here is currently the win32text stuff.
Mark Hammond said he w
This is a repost from two weeks ago. It didn't get much feedback last
time. I still keep trying, reposting to python-list also this time.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
Item 1
--
Th
This is a repost from a month ago. It didn't get much feedback last
time. I have now two items.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
Item 1
--
The first item is build identification. If y
> I do want to help, but I believe I'll only have time a week from now.
> If we need/want Roundup tweaks to go with Mercurial, I can work on
> that (keep in mind we have a cool GSoC student working on
> Mercurial-Roundup integration, and I'm willing to work on our needs
> with him).
I think that's
Hi Martin,
"Martin v. Löwis" wrote:
> In this thread, I'd like to collect things that ought to be done
> but where Dirkjan has indicated that he would prefer if somebody else
> did it.
>
> So far, I have only one item: build identification. If you want to work
> on this, please either provide a pa
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
So far, I have only one item: build identification. If you want to work
on this, please either provide a patch (for trunk and/or py3k), or
(if you are a co
76 matches
Mail list logo
