"LD 'Gus' Landis" <[EMAIL PROTECTED]> writes:
> Hi,
>
> So, what does one get when built on a system not connected to
> the net? say from a tarball?
Um, the two things you mention are unrelated. svnversion doesn't
access the network, so the first thing is moot. For the second, we've
talked
Hi,
So, what does one get when built on a system not connected to
the net? say from a tarball? It can happen, ya know.
Cheers,
--ldl
On 12/18/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Barry Warsaw wrote:
> > Yes, here's my thought: I have a mod to Makefile.pre.in and
> > getbuild
John Pinner wrote:
> It's also the only thing that identifes the revision/build precisely,
> allowing reversion to a known state.
How so?
- It doesn't identify a build precisely: you may have dynamically-loaded
modules that get rebuild even though the build number doesn't change.
So a single b
>
> Barry Warsaw wrote:
>
>>On Sun, 2005-12-18 at 19:19 +0100, "Martin v. L?wis" wrote:
>>
>>
>>
>>>It stopped counting builds on Windows quite some time ago; perhaps it
>>>is best to drop the build number entirely?
>>
>>
>>I think so, because it doesn't really convey anything useful.
>>
>
> I t
Barry Warsaw wrote:
> On Sun, 2005-12-18 at 19:19 +0100, "Martin v. Löwis" wrote:
>
>
>>It stopped counting builds on Windows quite some time ago; perhaps it
>>is best to drop the build number entirely?
>
>
> I think so, because it doesn't really convey anything useful.
>
I thought it was more
On Sun, 2005-12-18 at 23:48 +0100, "Martin v. Löwis" wrote:
> What does that achieve? It will give you the latest revision at which
> getbuildinfo was changed (currently 41744).
Dunno. It's better than nothing I guess.
-Barry
signature.asc
Description: This is a digitally signed message part
Barry Warsaw wrote:
> Yes, here's my thought: I have a mod to Makefile.pre.in and
> getbuildinfo.c so that when we don't find .svn directory, we don't
> define the BUILD macro when we compile getbuildinfo.c. Then, in that
> file we have something like:
>
> #ifndef BUILD
> #define BUILD "$Revision
On Sun, 2005-12-18 at 19:19 +0100, "Martin v. Löwis" wrote:
> It stopped counting builds on Windows quite some time ago; perhaps it
> is best to drop the build number entirely?
I think so, because it doesn't really convey anything useful.
-Barry
signature.asc
Description: This is a digitally
On Sun, 2005-12-18 at 18:58 +0100, Armin Rigo wrote:
> On Sat, Dec 17, 2005 at 08:28:17PM -0500, Barry Warsaw wrote:
> > Done. r41744.
>
> Doesn't appear to work for me: sys.build_number receives the value from
> the buildno. Looking at the Makefile, the reason is that I'm building
> CPython in a
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> It stopped counting builds on Windows quite some time ago; perhaps it
> is best to drop the build number entirely?
+1. I don't see how the information it contributes is meaningful in
any way.
Cheers,
mwh
--
Gullible editorial staff continues t
Martin v. Löwis wrote:
> Propose first. I have the feeling that the feature will change forth
> and back if everybody gets to say something. I would call it
> sys.svnversion (because that's what it is).
Perhaps it could make sense for sys.svnversion to exist only in a debug
build. This way people
Armin Rigo wrote:
> Do we have any plan to make sys.build_number meaningful in the releases
> as well (generally compiled from an svn export, as Michael pointed out),
> or are we happy with a broken number in this case?
I'm actually a bit confused that Barry changed the meaning of "build
number" f
Armin Rigo wrote:
> Should I propose / check-in a patch to expose sys.build_info instead
> ("CPython", "41761", "trunk"), as this got positive feedback so far?
> It's also less surprizing than the current sys.build_number, which is a
> string despite its name.
fwiw, I'm still +1 on that.
___
Hi Barry,
On Sat, Dec 17, 2005 at 08:28:17PM -0500, Barry Warsaw wrote:
> Done. r41744.
Doesn't appear to work for me: sys.build_number receives the value from
the buildno. Looking at the Makefile, the reason is that I'm building
CPython in a separate directory (running '/some/path/configure; ma
On Sat, 2005-12-17 at 23:48 +0100, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > AFAICT, the reason to use -c is so that changes outside the Python
> > source tree (i.e. in the sandbox) won't show up in Python's build
> > number. That's fine although I wouldn't mind leaving off the -c since
>
Barry Warsaw wrote:
> AFAICT, the reason to use -c is so that changes outside the Python
> source tree (i.e. in the sandbox) won't show up in Python's build
> number. That's fine although I wouldn't mind leaving off the -c since
> you'll still get the same snapshot of code from a revisioned checko
On Fri, 2005-12-16 at 17:11 -0500, Phillip J. Eby wrote:
> It looks like using 'svnversion -c . | cut -f2 -d":"' would get the
> most-recent committed version, plus the letter "M" if there are local
> changes. That sounds like what we should be using.
>
> That way, a build with local revisions
Michael Hudson wrote:
> For a different approach, would it be possible to have
> a subversion trigger put the revision number into some file in the
> repository?
Not easily, to my knowledge. Assuming that the export will be made
from a tag, the revision at which the tag was created (along with
the
Armin Rigo wrote:
> No, I know about this. I meant -- obviously, I'd have expected... --
> precisely the sequence of commands that my example shows:
I still managed to miss that point :-( My fault, you are right.
Regards,
Martin
___
Python-Dev mailing
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> that *still* won't tell you what precise sources had been used
> to build the binary, as different files simply can be on different
> revisions, and no single number, in whatever way computed, can
> give you full information.
A tangential point is t
Hi Martin,
On Sat, Dec 17, 2005 at 11:32:54AM +0100, "Martin v. L?wis" wrote:
> > trunk$ svn up
> > At revision xxx.
> > trunk$ svn info
> > Last Changed Rev: 1
> > trunk$ cd Python
> > trunk/python$ svn info
> > Last Changed Rev: 10001
>
> It is possible:
> sv
Armin Rigo wrote:
> If you meant that the following situation is possible:
>
> trunk$ svn up
> At revision xxx.
> trunk$ svn info
> Last Changed Rev: 1
> trunk$ cd Python
> trunk/python$ svn info
> Last Changed Rev: 10001
>
> then I object. As far as I can tel
Phillip J. Eby wrote:
> Only if you do an "svn update" immediately after *every* "svn commit".
> Otherwise, the code base reflected will be a version *before* your
> changes. This is fragile, since not everyone will know (or remember!)
> to do this.
That's true. It would be fairly reliable only
At 10:53 PM 12/16/2005 +0100, Fredrik Lundh wrote:
>fwiw, the official way to do this is to use svnversion:
>
> http://subversion.tigris.org/faq.html#version-value-in-source
>
>(this also looks for local changes).
It looks like using 'svnversion -c . | cut -f2 -d":"' would get the
most-recen
Phillip J. Eby wrote:
> I have not found any way to establish a stable "revision number" for a
> directory tree in Subversion except by using -R and "Last Changed Rev" (or
> the equivalent scanning of .svn/entries files). Through my experience
> working on setuptools in the sandbox, it is clearly
At 10:16 PM 12/16/2005 +0100, Armin Rigo wrote:
>Hi Phillip,
>
>On Fri, Dec 16, 2005 at 11:33:00AM -0500, Phillip J. Eby wrote:
> > >Not if you're happy with "Last Changed Rev":
> > >
> > > LC_ALL=C svn info | grep -i "last changed rev" | cut -f 4 -d " "
> >
> > You left off the all-important "
At 10:03 PM 12/16/2005 +0100, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > But you can also have more than one revision number that represents the
> > *exact same code*, with no changes at all.
>
>That's correct. I don't see this as a problem - in particular not in
>the context of the proposed
Hi Phillip,
On Fri, Dec 16, 2005 at 11:33:00AM -0500, Phillip J. Eby wrote:
> >Not if you're happy with "Last Changed Rev":
> >
> > LC_ALL=C svn info | grep -i "last changed rev" | cut -f 4 -d " "
>
> You left off the all-important "-R" from "svn info", and the "sort -nr |
> head -1" at the
Phillip J. Eby wrote:
> But you can also have more than one revision number that represents the
> *exact same code*, with no changes at all.
That's correct. I don't see this as a problem - in particular not in
the context of the proposed patch.
The idea is that you can reliably tell what code bas
At 08:30 PM 12/16/2005 +0100, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > The "Revision" from "svn info" isn't reliable; it doesn't actually relate
> > to what version of code is in the subtree. It can change when nothing has
> > changed.
>
>That is not true. It does relate - it is the revis
Phillip J. Eby wrote:
> The "Revision" from "svn info" isn't reliable; it doesn't actually relate
> to what version of code is in the subtree. It can change when nothing has
> changed.
That is not true. It does relate - it is the revision that was current
when "svn up" was last done. This *does
On Fri, 16 Dec 2005, Phillip J. Eby wrote:
[...to-and-fro re magic required to get a good SVN revision...]
Shouldn't the command 'svnversion' be used instead? -
http://svnbook.red-bean.com/en/1.1/re57.html
It's true that the output of this command does change with 'svn up', even
if the update
At 05:17 PM 12/16/2005 +0100, Armin Rigo wrote:
>Hi Phillip,
>
>On Fri, Dec 16, 2005 at 10:59:23AM -0500, Phillip J. Eby wrote:
> > The "Revision" from "svn info" isn't reliable; it doesn't actually relate
> > to what version of code is in the subtree. It can change when nothing has
> > changed.
>
Hi Phillip,
On Fri, Dec 16, 2005 at 10:59:23AM -0500, Phillip J. Eby wrote:
> The "Revision" from "svn info" isn't reliable; it doesn't actually relate
> to what version of code is in the subtree. It can change when nothing has
> changed.
Indeed, the patch should not use the "Revision" line bu
Hi Skip,
On Fri, Dec 16, 2005 at 05:02:19AM -0600, [EMAIL PROTECTED] wrote:
> Armin> ("trunk" is the last part of the path returned by "svn info".)
> Did you mean the last part of the URL?
Yes, sorry.
Armin
___
Python-Dev mailing list
Python-Dev@
Hi Phillip,
On Fri, Dec 16, 2005 at 10:51:33AM -0500, Phillip J. Eby wrote:
> svn info -R|grep '^Last Changed Rev'|sort -nr|head -1|cut -f 4 -d" "
>
> To get the highest-numbered revision. However, both this approach and
> yours will not deal with Subversion messages in non-English locales
At 07:42 AM 12/16/2005 -0800, Michael Chermside wrote:
>Phillip writes:
> > FYI, this is not the true revision number; it's only the revision number in
> > which the directory was last modified, not the latest revision number
> > within the tree.
>
>Barry responds:
> > I opted against that for seve
At 08:35 AM 12/16/2005 -0500, Barry Warsaw wrote:
>On Fri, 2005-12-16 at 01:38 -0500, Phillip J. Eby wrote:
>
> > FYI, this is not the true revision number; it's only the revision
> number in
> > which the directory was last modified, not the latest revision number
> > within the tree.
>
>Yep, I k
On Fri, 2005-12-16 at 01:38 -0500, Phillip J. Eby wrote:
> FYI, this is not the true revision number; it's only the revision number in
> which the directory was last modified, not the latest revision number
> within the tree.
Yep, I know. At work, we've gone through many iterations of this,
in
On Thu, 2005-12-15 at 22:13 -0800, Brett Cannon wrote:
> +0
>
> It makes it easy to request the revision number from people who submit
> patches and bugs. But I also don't find it vital since running ``svn
> info .``.
That's really more the point, that you can talk about a specific svn
revision
Armin> What about having instead:
Armin> sys.build_info = ("CPython", , "trunk")
Armin> This would make it clear that it's the CPython svn rev number,
Armin> and it could possibly be used to distinguish between branches,
Armin> too, which the revision number alone cannot
Armin Rigo wrote:
> What about having instead:
>
> sys.build_info = ("CPython", , "trunk")
>
> This would make it clear that it's the CPython svn rev number, and it
> could possibly be used to distinguish between branches, too, which the
> revision number alone cannot do. ("trunk" is the last
Hi Barry,
On Fri, Dec 16, 2005 at 12:16:49AM -0500, Barry Warsaw wrote:
> SF patch # 1382163 is a fairly simple patch to expose the Subversion
> revision number to Python, both in the Py_GetBuildInfo() text, and in a
> new Py_GetBuildNumber() C API function, and via a new sys.build_number
> attrib
At 12:16 AM 12/16/2005 -0500, Barry Warsaw wrote:
>SF patch # 1382163 is a fairly simple patch to expose the Subversion
>revision number to Python, both in the Py_GetBuildInfo() text, and in a
>new Py_GetBuildNumber() C API function, and via a new sys.build_number
>attribute. This number is calcul
On 12/15/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> SF patch # 1382163 is a fairly simple patch to expose the Subversion
> revision number to Python, both in the Py_GetBuildInfo() text, and in a
> new Py_GetBuildNumber() C API function, and via a new sys.build_number
> attribute. This number is
SF patch # 1382163 is a fairly simple patch to expose the Subversion
revision number to Python, both in the Py_GetBuildInfo() text, and in a
new Py_GetBuildNumber() C API function, and via a new sys.build_number
attribute. This number is calculated from the output of "svn info" at
the top of the t
46 matches
Mail list logo
