X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <53286E8C.8060403@buffalo.edu>
Date: Tue, 18 Mar 2014 12:04:28 -0400
From: "Stephen R. Besch" <sbesch AT buffalo DOT edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] pcb-20140316 is released
References: <201403170355 DOT s2H3tavv007601 AT envy DOT delorie DOT com> <532741F8 DOT 8090101 AT buffalo DOT edu> <201403171845 DOT s2HIj1kj012076 AT envy DOT delorie DOT com> <20140317185419 DOT GB5081 AT localhost DOT localdomain> <DUB125-W257D599B410B568111A209C67C0 AT phx DOT gbl> <20140318073922 DOT 25660 DOT qmail AT stuge DOT se>
In-Reply-To: <20140318073922.25660.qmail@stuge.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PM-EL-Spam-Prob: X: 10%
Reply-To: geda-user AT delorie DOT com

On 03/18/2014 03:39 AM, Peter Stuge wrote:
> Hannu Vuolasaho wrote:
>> However I would like to see some git magic to happen and
>> when I click window about I would get date of the last commit
>> and commit ID. I sometimes forget to pull before make.
> A nice way is to call git describe --tags in the build scripts, and
> put the output in a #define.
>
>
> //Peter
>
>
The versioning stuff does get complicated, particularly when project 
history is factored in. Git doesn't help since it does not  maintain a 
revision counter. However, this is really not very hard to fix. Use a 
server side "post-receive" and "pre-receive" scripts to increment a 
counter that is kept in a text file with the date of the push. This text 
file would be located in the project's root directory. Each branch could 
also have it's own independent counter. Then each time a group of 
changes is pushed, the counter would be updated and time-stamped. Anyone 
Pulling or Cloning the project would get the most recent revision count. 
This data could then be used by the project to maintain and display the 
version/revision data.

This fits really well with the classical 3 part version 
(Major.Minor.Revision). Simply divide the count by 100 and use the 
result as Minor.Revision. This would mean that each major version could 
represent 10,000 pushes into the git repo and no Major version should 
stay the same over that many revisions anyway.  You might also be able 
to make use of the Pre-Commit hook on the client side, but this has 
other problems - i.e. Client side hooks are not part of clones,  
checkouts, etc., not to mention that each copy of the Repository would 
have it's own commit count. However, maintaining a "commit count" for 
project history could be interesting. This could be done with a server 
side hook that kept a log of all commit counts and a running total - 
probably more trouble than it's worth.

Steve Besch

-- 
fictio cedit veritati