Hi Mike,
I think it’s more than obvious, the tools developers need are not always in
line with what end-users expect to see. I’m not sure what you mean by
“collisions”. What I do know is, there are many projects that have hundreds—in
some cases thousands--of developers working from / on the same code base; the
Linux Kernel being one of them, and they are using Git as their VCS ( thanks to
Mr. Torvalds for another gift 😊 ).
The bottom line is, the WSJT project has grown to the point where SVN was no
longer a viable solution for the developers. There will no doubt be a learning
curve—and a bit of pain along the way--for those not in the core development
team. We’ve seen these same pains when moving from WSJT to WSJT-X; the original
WSPR to WSJT-X WSPR, and so on.
Generating an arbitrary number (which already exists with git rev-list by the
way) is meaningless other than the integer changing (maybe not totally
meaningless, but hey-ho). Git History, as Bill pointed out earlier, and Git
Log, are powerful tools once folks come to terms with some basic syntax. Entire
projects devote endless hours to making pretty command line and UI based Git
revision history tools. At the end of the day, the only “numbers” that really
matter are those the development team tag for general availability usage.
Everything else is merely the next step toward an eventual release.
We should cute the dev-team some slack. Restructuring the entire svn repository
from a folder based archive, to that of a distributed control system is no
small feat. From where I’m sitting, the shift seems to be working well, and as
expected.
73’s
Greg, KI7MT
From: Black Michael via wsjt-devel [mailto:[email protected]]
Sent: Monday, July 9, 2018 9:49 PM
To: [email protected]
Cc: Black Michael <[email protected]>
Subject: Re: [wsjt-devel] Building WSJT-X Developmental Software
I was speaking from a human/user perspective as I'm aware what a hash
is...although collisions in git can occur (unlikely) which never occur in a
one-up counting system (barring rollover).
If one were to say "XXXXXX" is the most current version of WSJT-X the vast
majority of users would not know how to figure out if they are current or not.
Bad to assume people building wsjtx know git. Ergo my comment which again, was
made from a human perspective that it's not a very good system...for users of
WSJT-X. Works fine for developers and configuration control. And when one
says a problem was fixed in "XXXXXX" nobody (and I mean nobody) can know if
their WSJT-X contains that change without grepping the git log to know if it's
in there.
We will be seeing more of this same question in the future I'm sure so some
consideration should be given to making it a one-up counter again perhaps
appending it to the 6-digit git number.
de Mike W9MDB
On Monday, July 9, 2018, 6:35:11 PM CDT, Bill Somerville <[email protected]
<mailto:[email protected]> > wrote:
Hi Mike,
some comments in line below.
On 09/07/2018 17:51, Black Michael via wsjt-devel wrote:
> No...that number does not increment...it's basically random with git
> (it's a hash value). It's just the first 6 digits of the "commit"
> line which is a hexadecimal number
The git SHA-1 hash codes are not random, anything but in fact. They are
a unique representation of a commit and all it's history that is
reproducible with absolute certainty even if the commit is moved to a
different repository. This is key to how git can maintain integrity
across distributed and unconnected repositories.
>
> There is a means to making an increment version # but it's not
> frequently used -- basically one way is to count the # of log entries.
It is basically futile and pointless on anything but the most trivial
centralized work flow model with no branching, ever.
>
> As long as your version matches the most recent log entry 6-digit
> number you're current. And yes...it's not a very good system as one
> can't say "ensure you are at least version X".
That was never true even with Subversion since svn revision numbers are
common to all branches. An svn revision number is no more than a label
for a change set on some branch. All it's magnitude tells you is when
the commit was made with respect to another, but since consecutive
commits could be to different branches, that tells you little or nothing
about the logical lineage of a revision.
Your definition of "not a very good system" is based on a very poor
system as a reference point, so not a very good argument ;)
>
> de Mike W9MDB
>
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected] <mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
