Am 29.12.2010 18:54, schrieb Jesse Noller:
> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis"
> wrote:
>>>> I would like to know if it should be considered as a release blocker.
>>>> Georg Brandl said yes on IRC.
>>>
>>> Under t
, the ridiculous low limits seem to be
difficult to detect, and it's not clear what a required minimum level
should be.
Regards,
Martin
___
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
to the test that skips if broken functionality
on BSD is detected?
Regards,
Martin
___
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
sible
approach to do IPC synchronization on FreeBSD, so it's better to say
that multiprocessing is not supported on FreeBSD (until SysV IPC is
getting used, hoping that this will fare better).
Regards,
Martin
___
Python-Dev mailing li
Am 29.12.2010 22:34, schrieb Jesse Noller:
>
>
> On Dec 29, 2010, at 3:49 PM, "Martin v. Löwis" wrote:
>
>>> If the functionality is not supported then users get an import error
>>> (within multiprocessing). However, RDM's understanding is co
authors, or the concurrent.future authors.
Meanwhile, we must admit that it just doesn't work (or else the
test case would not fail).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
Am 30.12.2010 04:45, schrieb Brian Quinlan:
> On Dec 29, 2010, at 2:55 PM, Victor Stinner wrote:
>
>> Le mercredi 29 décembre 2010 à 21:49 +0100, "Martin v. Löwis" a écrit :
>>> Of course, one may wonder why test_first_completed manages
>>> to create 41 Sem
ng itself (or perhaps even some core Python functionality).
> Actually, the threading-based part of concurrent.futures probably works
> fine.
Well, "the culprit" really is FreeBSD. However, concurrent.futures
apparently makes freehanded use of semaphores, in a way that the
FreeBSD
PI to move
the executors to the submodules, or we let creation of process pools
fail (rather than the import).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
e
POSIX semaphores if the system doesn't conform to POSIX, i.e.
has semaphore limit of less than 256.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
I think the new workflow will simply result in (even) less care for the
maintenance branches than currently. Some people just refuse to
patch multiple branches, and will continue to do so. While it was
previously possible to backport, it won't be that easy anymore in
the future, so it just won
, just like
> the mass merging we had once from trunk -> py3k (just more convenient for
> the one doing the merge).
But you can't use Mercurial's merge functionality for that, right?
You have to use some kind of transplant/cherry-picking to merge from the
3.3 branch to the
ge tool?
Neither nor. They come from "hg merge" being useless when it comes
to having code that is meant to live both on 2.7, 3.2 (perhaps) and
3.3.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Am 30.12.2010 21:36, schrieb Ethan Furman:
> Martin v. Löwis wrote:
>>> And, again, the threading-based API in concurrent.futures should work
>>> fine anyway. Do you suggest we selectively disable the process-based
>>> API?
>>
>> Yes. Importing concurr
em.c?rev=1.22&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
SEM_MAX is 128 since 2007, and dynamically adjustable (no reboot).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
"kern.posix.semmax"
> - Darwin: "kern.posix.sem.max"
> - OpenBSD: (no support)
I've been using os.sysconf("SC_SEM_NSEMS_MAX"), which seems to have
worked fine (it's also what POSIX mandates). See #10798.
Regards,
Martin
___
are going to contribute to, as a proof that they actually
know how to write code. So I suggest you browse through the bug tracker,
find an open issue with no patch, and write a patch. You may want to
focus on issues marked as "easy".
Regards,
Martin
_
> BTW: I've been doing gcc pre-release testing regularly for many year,
> starting
> with gcc 3.3. This is the first time I see the Python build fail persistently
> for several weeks.
Wild guess: did configure detect that it needs to use -fno-strict-aliasing?
d
run the copying
b) the data are not even copied into userspace at all
My guess is that the savings of doing a) are larger than the savings
of doing b).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
eate an URL like this through the search form.
Regards,
Martin
___
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
ccepted.
Of course, there may be limitations with respect to operating systems,
and in the way Python modules integrate with the file system - but
that non-ASCII module names must be supported is really out of question.
If you would like this to be reverted, you need to write another PEP
the tools will improve. It took PKWARE
many years to come up with a reasonable Unicode story - but now it's
really the tools that need to catch up, not the spec.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
ngs on your computer, such as using a
non-standard cmd shell?
Regards,
Martin
___
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
indicator: the smaller the framework, the more easy should
it be to port it.
HTH,
Martin
___
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/
quot;) existed!?
I'd really like to understand it before changing it. The part "it
sometimes works, then fails" is particularly puzzling, and indicates
that the *actual* problem is entirely unrelated to the quoting.
Regards,
Martin
___
Pyt
7;s a design flaw in CPython that there are two ways to report
an exception: either through the thread state, or through the return
value. I don't think this flaw can be fully fixed. However, I
wonder whether static analysis of the C code could produce better
det
don't really understand.
It's one thing how the file systems are formatted, but another thing
how they are presented to APIs. For example, the phones using Windows CE
would have to convert the file names to Unicode in the OS kernel.
So: for these phones - do you know
s/pep-0393/
For convenience, I include it below.
Regards,
Martin
PEP: 393
Title: Flexible String Representation
Version: $Revision: 88168 $
Last-Modified: $Date: 2011-01-24 21:14:21 +0100 (Mo, 24. Jan 2011) $
Author: Martin v. Löwis
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
C
support
UTF-8. As Oleg explains: you need one encoding for the bytes on disk
(to know what they mean, when converted to Unicode), and one encoding
to then convert the "abstract" unicode to bytes again to present to
the application. This is similar to how *A works on Windows.
The ioc
contradict to having
a non-trivial __init__.py, and no __path__-munging will be necessary.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
rst (which is actually cheaper
than starting with the implementation only to find out that people
misunderstood each other).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
changes
whatsoever to the tree (but it's Georg's decision, of course).
Regards,
Martin
___
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
errers to thingy: the class dict, and the module dict.
The class dict will have a __module__ key.
I agree the program should print 2, though.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
simultaneously on two systems, with no file name conversion
(unless you are using NFSv4, and unless your NFSv4 implementations
support the UTF-8 mandate in NFS well).
Also, if two users of the same machine have different locale settings,
the same file name might be interpreted differently.
Rega
r of keeping the current code base.
Just make sure you understand the reasoning of those opposing.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
> UTF-8.
In fact, convmv (http://j3e.de/linux/convmv/) does exactly that;
it comes as a Debian package also.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
there's this proposal: http://bugs.python.org/issue1943
I wonder what aspects of this patch and discussion should be integrated
into the PEP. The notion of allocating the memory in the same block is
already considered in the PEP; what else might be relevant?
I
t is rarely the
> right thing to do. Of course I'd personally like to see PyObject
> nuked and revisited, it is too large and is probably not cache line
> efficient.
That's a different PEP :-)
Regards,
Martin
___
Python-D
serve another bit in the state for that.
> GDB Debugging Hooks
> ---
> Tools/gdb/libpython.py contains debugging hooks that embed knowledge
> about the internals of CPython's data types, include PyUnicodeObject
> instances. It will need to be slightly updated to t
Am 25.01.2011 12:08, schrieb Nick Coghlan:
> On Tue, Jan 25, 2011 at 6:17 AM, "Martin v. Löwis" wrote:
>> A new function PyUnicode_AsUTF8 is provided to access the UTF-8
>> representation. It is thus identical to the existing
>> _PyUnicode_AsString, which is removed
of -10MB compared to
> today's implementation :-)
As others have pointed out: that's not how it works. It actually *will*
save memory, since the alternative representations are optional.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev
Am 27.01.2011 20:06, schrieb Stefan Behnel:
> "Martin v. Löwis", 24.01.2011 21:17:
>> The Py_UNICODE type is still supported but deprecated. It is always
>> defined as a typedef for wchar_t, so the wstr representation can double
>> as Py_UNICODE representatio
gt; page, etc. Personally I would rather have http://www.python.org/2.7
> redirect to 2.7.1, but since that already redirects to 2.7.0 I doubt
> people would be okay with the change.
How about http://www.python.org/2.7.x redirecting to the latest 2.7.x
r
Py: the actual string
operations are written in RPython, and the tracing JIT would generate
all versions of the code that are relevant for the different
representations (IIUC, this approach is only planned for PyPy, yet).
I hope that C macros can help reduce the
ged.
I'm only going to change the release redirects now.
Regards,
Martin
___
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
> Works for me! Short and elegant.
Done!
http://www.python.org/2.6.x
http://www.python.org/2.x
http://www.python.org/3.1.x
http://www.python.org/3.x
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
Am 27.01.2011 23:53, schrieb Stefan Behnel:
> "Martin v. Löwis", 24.01.2011 21:17:
>> If the string is created directly with the canonical representation
>> (see below), this representation doesn't take a separate memory block,
>> but is allocated right after t
n anymore - that's the whole
point of the PEP.
> While I'm somewhat confident that I'll
> find a way to fix this in Cython, my point is just that this adds a
> certain level of complexity to C code using the new memory layout that
> simply wasn't there before.
Unde
rk on
> unicode buffers in the future as long as they only use the 'str' pointer
> and not 'wstr'.
Py_UNICODE isn't part of the stable ABI, so it wasn't important for
extensions using the stable ABI before - so really no change here.
Regards,
Martin
t; (i.e. "module.so") goes back to r4297 (Python 1.1),
when the short extension was added as an alternative to the long
extension. The original module suffix was defined in r3518 when
dynamic extension modules got supported, as either "module.so"
(SUN_SHLIB) or "modul
is that it matters more if you look into ten
directories instead of one).
Regards,
Martin
___
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
with not
reading the entire directory (whereas it will have to when we explicitly
ask for that).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
really compare zip reading with directory
reading - I'd expect that reading a zip directory is signficantly faster
than reading the directory contents of the zip file unpacked, just
because this is so many fewer layers of indirection.
Regards,
Martin
__
Am 31.01.2011 22:13, schrieb anatoly techtonik:
> Ok. Here is the patch. I used Orca to reverse installer tables of
> Mercurial MSI and inserted similar entry for Python.
This doesn't do uninstallation correctly.
Regards,
Martin
___
Python-
ontinued, so perhaps someone more senior should chime
> in. :)
As a mailing list, it was unmaintainable, since there was no tracking
of what patches still need consideration. So a web-based bug tracker
got into use (although I forgot the name of the tracker software t
support was added, we would have to
wait until the version containing it isn't maintained anymore).
I don't consider the dependency on win32com a serious issue at
all; it's just a mild annoyance (much less than reliance on ctypes
would be, or hard-coding of symb
d to move
away from that - it can create arbitrary MSI files.
Regards,
Martin
___
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
to maintain an XML file than an entire
> lib dedicated to something that someone else has already solved?
Definitely not. Python is easier than XML.
If you think otherwise, feel free to provide a proof in the form of
a Wix installation generator for Python.
Regards,
Martin
_
, which slightly predates Wix in
time). However, I don't see any need to switch, and I actually do
believe that Wix couldn't provide a feature-by-feature full
replacement of the current packaging code (but I might be wrong).
Regards,
Martin
__
an translate it into WiX if I thought it'd be
> used (but why bother if no one's interested?).
It's in Tools/msi/msi.py.
Regards,
Martin
___
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
would be no reason to move to Wix. Integrating the same algorithm
in msilib is trivial.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
nsure how versioning would work,
in particular if I have per-directory components, and files get added
(which typically shouldn't, but might happen in bugfix releases).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
> The general recommendation regarding msi packages is that you always,
> always do single-file components (one of the major reasons being for
> patching purposes).
Can you please cite a source for that recommendation? Preferably
some MSDN documentation.
Regard
e forward-compatible (?), i.e.
all modules build for 3.2 would continue to work in 3.2.1.
However, modules using them would work in 3.2.1, but fail in
3.2.0 (with a RuntimeError exception)
So I think I would preferably add these before 3.2 is releas
is point. I believe the change, if
implemented, needs to be optional (which I believe your change is not).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
and more API gets documented.
HTH,
Martin
___
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
ow
widely the API is being used.
More explicitly: while it is policy to consider alternative
implementations when changing the language or the standard library,
it is not policy to consider alternative implementations when
changing the C API.
Regards,
Martin
___
5
12434 | 25
(2 Zeilen)
It might still be useful to test it, since actually evaluating the
property might also go wrong, but that should be fine as well:
for component in components:
users = db.component.get(component, 'add_as_nosy')
nosy |= set(user
I'm going to perform a Debian upgrade of svn.python.org on Friday,
between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
that time. The outage shouldn't be longer than an hour.
Regards,
Martin
___
Python-Dev mailing
nd, failing that, should start at PyCon.
Regards,
Martin
___
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
Am 18.02.2011 14:41, schrieb Dirkjan Ochtman:
> On Tue, Feb 15, 2011 at 09:30, "Martin v. Löwis" wrote:
>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>> that
idered.
Regards,
Martin
___
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
*, it just means the precompiled file will be ignored on first
>> execution with newer Python versions.
>
> Are you sure? If the package gets installed in a root-writable-only
> directory, later execution cannot create the right pyc files.
It will certainly work. It won't c
http://bugs.python.org/issue2405
Read the report carefully. It can't be removed to support installations
that have changed COMSPEC.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
T (in the popen library function).
Regards,
Martin
___
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
nobody cared about adding const
there).
Regards,
Martin
___
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
ple likely use string literals, and since g++ only started
warning about the deprecated conversion only recently, most people
probably haven't run into the issue.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
> The very long term view is for %-formatting to go away
Add to that that this view isn't universally shared among contributors.
Many of us would rather see % formatting stay indefinitely. I regularly
use it for new code.
Regards,
Martin
___
Py
als in,
> without having to trawl through the interpreter source to see if the
> arguments are modified.
Can you provide the proper patches?
In writing them, you can assume that Python never modifies parameters,
except when it is already documented that it
ourse (i.e. code relying on the bug fix will
reasonably break when used with buggy versions).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Am 23.02.2011 02:43, schrieb Nick Coghlan:
> On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. Löwis" wrote:
>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>> that
since.
Regards,
Martin
___
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
torial -
"you can get Python only if you read through this".
Regards,
Martin
___
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
t's certainly possible to redirect ^/dev$ to
/devguide, leaving /dev..* alone. I can set this up if you want me to.
Regards,
Martin
___
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
u edit specifically?
I have now changed redirects.conf, and it seems to work fine. Please
let me know if there are any problems.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
ed it. If there
are any other redirects that you want to see active, please
let me know.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
ones for feature branches, rather than putting all
in a single repository).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
executed
can cause the failure. Or it's specific to the Windows installation,
and some interaction with the virus scanner, in which case you
should ask Brian for remote-desktop access to the build slave
in order to reproduce it.
HTH,
Martin
___
Python-
Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:
> On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote:
>> I think I would have liked the strategy of the PEP better (i.e.
>> create clones for feature branches, rather than putting all
>> in a single repository).
&g
Am 25.02.2011 09:29, schrieb Dirkjan Ochtman:
> On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" wrote:
>> If there are hundreds of them, it's far from trivial. I don't even know
>> how to find out which one to convert.
>
> Right, I mostly mean it'
account managers are then, of course, free to establish any workflow
they deem appropriate.
> +* adapt build identification for Windows build process
I think this should also be done before the migration.
Regards,
Martin
___
Python-Dev mailing list
Pyt
quot; as a svn think. If that doesn't
clue them in, they will ask, and every other person will know.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
k" branch.
What's the effect of "closing" a branch in Mercurial?
I can still commit to it, hg branches still shows it
(but shows 3.2 as "inactive"???). How can I find out
that the branch is closed?
Regards,
Martin
___
Python
> Committing reopened it
So what's the point of closing it, then? What effect does that
achieve?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
Am 26.02.2011 15:42, schrieb Nick Coghlan:
> On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote:
>>> I think people should simply get used to the idea that "default" is
>>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
&
> Although I now admit "legacy-trunk" sounds quite accurate, and conveys
> a clear warning to anyone wondering if they should use it.
To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk".
Bikeshedding is such a fun activity :-)
Regards,
Marti
unk" named branch?
Couldn't the historical changesets just be in an unnamed branch, being
ancestor of so many named branches?
I'd like to prevent people from mistakenly committing onto the trunk,
which would be easiest if trunk didn't exist at all.
Regards,
Mart
sues
with CRLF, leading to catastrophic repository corruption).
So I think it's absolutely necessary that files with incorrect
eol-style are blocked from being pushed. Or else we will all
suffer and eventually die :-)
Regards,
Martin
___
order 2.0, 2.1, 2.2, ... 2.7.
So e.g. the 2.7 branch would go back to where it branched from the 2.6
branch (after the actual creation of the 2.6 branch in svn), which
would go back to where it branched from 2.5, and so on.
Regards,
Martin
___
Pyt
Am 26.02.2011 19:12, schrieb Barry Warsaw:
> Notice the subject line. Can we make commit messages contain the named branch
> that the change applies to?
If you don't want this request to be forgotten, add it to todo.txt in
the pymigr repo.
Rega
2701 - 2800 of 5755 matches
Mail list logo
