>> My assumption was that most developers don't use MSVC, so most of them
>> don't risk breaking eols ;)
>> True, for Windows devs it might be necessary to promote it.
>
> Windows devs were the original target audience, yes :)
I meant to say that earlier: thanks to everybody involved in the
origi
>> I think this is overly optimistic. Visual Studio will break all your
>> files if you don't use that extension (and you actually use it to
>> modify source code).
>
> My assumption was that most developers don't use MSVC, so most of them
> don't risk breaking eols ;)
> True, for Windows devs it
On Mon, Feb 28, 2011 at 1:12 AM, Antoine Pitrou wrote:
> On Sun, 27 Feb 2011 07:46:51 +0100
> "Martin v. Löwis" wrote:
>> > Actually, it isn't *required* on each developer's setup, since we
>> > now have a hook that refuses bogus changegroups (if needed, we can even
>> > refuse individual changes
On Sun, 27 Feb 2011 07:46:51 +0100
"Martin v. Löwis" wrote:
> > Actually, it isn't *required* on each developer's setup, since we
> > now have a hook that refuses bogus changegroups (if needed, we can even
> > refuse individual changesets). In most situations, even without the
> > eol extension l
> Actually, it isn't *required* on each developer's setup, since we
> now have a hook that refuses bogus changegroups (if needed, we can even
> refuse individual changesets). In most situations, even without the
> eol extension line endings won't get modified anyway.
I think this is overly optimi
Hi,
On Sat, 26 Feb 2011 18:13:15 -0500
Dj Gilcrease wrote:
>
> File Format Management
> eol
> http://mercurial.selenic.com/wiki/EolExtension
> required
Actually, it isn't *required* on each developer's setup, since we
now have a hook that refuses bogus changegroups (if need
On Sun, 27 Feb 2011 01:25:12 +0100
Éric Araujo wrote:
> > I've just tried bookmarks and I find them very cumbersome compared to
> > named branches (which, unfortunately, can't remain local). I wonder
> > what guided their design.
>
> Mimicking git branches.
I've hardly ever used git but I would
> I've just tried bookmarks and I find them very cumbersome compared to
> named branches (which, unfortunately, can't remain local). I wonder
> what guided their design.
Mimicking git branches.
> (the core issue being that a bookmark blindly follows every commit you
> do, while you would need it
> >> Branch Management
> >> bookmarks
> >> http://mercurial.selenic.com/wiki/BookmarksExtension
> >> Great for tracking bug fix work without needing to create a
> >> separate working directory
> > Never use them. Clones are okay.
>
> Same here but not everyone likes to do that
On 2011-02-27 00:13, Dj Gilcrease wrote:
> Branch Management
> bookmarks
> http://mercurial.selenic.com/wiki/BookmarksExtension
Bookmarks will be in Mercurial core for Mercurial 1.8, which will be
released in a few days (March 1st). So, with 1.8 it's no longer needed
to enable this ext
On Sat, Feb 26, 2011 at 6:19 PM, Éric Araujo wrote:
>> transplant
>> http://mercurial.selenic.com/wiki/TransplantExtension
>> required to port patches between major versions
> That’s actually not clear in the current PEP / devguide.
http://potrou.net/hgdevguide/committing.html#
> Never use them. Clones are okay.
s/use/used/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Hi,
> shelve
> http://mercurial.selenic.com/wiki/ShelveExtension
> Store un commited changes away so they dont affect generation
> of the patch
I never use it.
>transplant
> http://mercurial.selenic.com/wiki/TransplantExtension
> required to port patches be
So reading the thread about the conversion and the dev guide at
http://potrou.net/hgdevguide/ there seems to not be a list of
recommended extensions that the python devs should have and use, only
a few examples of their use. so I figured I would build up a list for
other people to add to / comment
14 matches
Mail list logo
