including a checksum of the diff in uname

[Mateusz Guzik]

Hi all,
I often have several variants of the same revision that I'm testing or
working on at any given time.
Index: sys/conf/newvers.sh
===================================================================
--- sys/conf/newvers.sh (revision 333575)
+++ sys/conf/newvers.sh (working copy)
@@ -203,6 +203,8 @@ if [ -n "$svnversion" ] ; then
[0-9]*[MSP]|*:*)
svn=" r${svn}"
modified=true
+ ck="$(svn diff | cksum | cut -w -f 1)"
+ svn="$svn-$ck"
;;
[0-9]*)
svn=" r${svn}"
to help differentiate.
You end up with a version that looks like: r333575M-4294967295?

Don't develop with svn. get yourself a git or hg setup and a tmp branch.
The branch name is always included along with the commit hash.

The benefit is that not only know you know what the change is, you can
always refer back to it later and diff against something else.

[David Wolfskill]

Hi all,
I often have several variants of the same revision that I'm testing or
working on at any given time.
....

Well....

The variant of newvers.sh that I use addresses this (among other
things) by sourcing a file (through a symlink) that defines a shell
function named "get_version_from_vcs()," and invokes that function
in order to obtain a suitable "version string."

The primary rationale for this is that I don't believe the various
quirks of VCSen or installations ought to be in newvers.sh proper: it
adds a fair amount of complexity that is difficult to test completely to
code that has a fairly critical (and fundamentally simple) function.

I created a few sample such functions, though I don't use all of the
VCSen currently supported by base newvers.sh, so I haven't been able to
test them all.

(Sorry about the name. I'm lousy at naming things, and have no
"investment" in the names used. I'd be pleased if someone would take
the idea and get something based on it implemented, though.)

Anyway, using such a mechanism, you could easily extend to version
string to include just about anything you wanted -- with minimal
risk of breaking newvers.sh (either for yourslef or others).

Peace,
david

[Eitan Adler]

Post by Mateusz Guzik

Hi all,
I often have several variants of the same revision that I'm testing or
working on at any given time.
Index: sys/conf/newvers.sh
===================================================================
--- sys/conf/newvers.sh (revision 333575)
+++ sys/conf/newvers.sh (working copy)
@@ -203,6 +203,8 @@ if [ -n "$svnversion" ] ; then
[0-9]*[MSP]|*:*)
svn=" r${svn}"
modified=true
+ ck="$(svn diff | cksum | cut -w -f 1)"
+ svn="$svn-$ck"
;;
[0-9]*)
svn=" r${svn}"
to help differentiate.
You end up with a version that looks like: r333575M-4294967295?

Don't develop with svn. get yourself a git or hg setup and a tmp branch.
The branch name is always included along with the commit hash.

That makes sense, and I might do that in the future. In the past
adding files was more painful with git, though I'm told this is no
longer the case.

In any case, is there any reason not to add the above patch?

[Mateusz Guzik]

Post by Eitan Adler

Post by Mateusz Guzik

Hi all,
I often have several variants of the same revision that I'm testing or
working on at any given time.
Index: sys/conf/newvers.sh
===================================================================
--- sys/conf/newvers.sh (revision 333575)
+++ sys/conf/newvers.sh (working copy)
@@ -203,6 +203,8 @@ if [ -n "$svnversion" ] ; then
[0-9]*[MSP]|*:*)
svn=" r${svn}"
modified=true
+ ck="$(svn diff | cksum | cut -w -f 1)"
+ svn="$svn-$ck"
;;
[0-9]*)
svn=" r${svn}"
to help differentiate.
You end up with a version that looks like: r333575M-4294967295?

Don't develop with svn. get yourself a git or hg setup and a tmp branch.
The branch name is always included along with the commit hash.

That makes sense, and I might do that in the future. In the past
adding files was more painful with git, though I'm told this is no
longer the case.
In any case, is there any reason not to add the above patch?

I don't see any added value of doing so. So far it just looks like
patching up a deficient development process.