[Novalug] Developer question(s)-- things have changed! (rcs $Id$ in git?)

James Ewing Cottrell 3rd JECottrell3@Comcast.NET
Wed Jun 1 14:04:48 EDT 2011


  [1] go to YouTube
[2] search for Linus Git Talk

It's about 70 minutes. Very Enlightening.

JIM

On 5/31/2011 6:43 PM, greg pryzby wrote:
> And I would LOVE a git talk at a future meeting.
>
>
> On Tue, May 31, 2011 at 6:22 PM, Jason Kohles<jkohles@palantir.com>  wrote:
>> in that case there isn't any need for arguing.  :). Git has tagging, and IMHO it's better thought out than subversions "it's a tag because it's in a directory named 'tags'" implementation.  In git a tag is basically a checkpoint that says "at the time this tag was made, the repository contained these changesets".
>>
>>
>>
>> Jason Kohles
>> Palantir Technologies | UNIX Systems Engineer
>> jkohles@palantirtech.com | 703.957.5784
>>
>> ----- Original Message -----
>> From: Peter Larsen [mailto:plarsen@famlarsen.homelinux.com]
>> Sent: Tuesday, May 31, 2011 02:47 PM
>> To: Jason Kohles
>> Cc: novalug@calypso.tux.org<novalug@calypso.tux.org>
>> Subject: Re: [Novalug] Developer question(s)-- things have changed! (rcs $Id$ in git?)
>>
>> (see comments below)
>>
>> On Tue, 2011-05-31 at 12:58 -0700, Jason Kohles wrote:
>>> The big difference is that when you used $Version$ with CVS, every file
>>> had it's own distinct version number, and it made sense to be able to put
>>> that information into the file.
>>>
>>> With subversion people get all confused by the fact that each file doesn't
>>> have it's own specific version,  instead you have just one revision number
>>> for each commit (which may cover multiple files), so you end up with
>>> people doing odd things to try and make the subversion revision number
>>> *look* like a version number (I'm sure if you look hard enough you can
>>> find some of my old perl code that does things like '$VERSION = sprintf(
>>> '1.%03d', qw$Version$').
>>>
>>> With git this is even more meaningless, because instead of trying to
>>> manipulate a revision number into a version, you have a 40-character
>>> cryptographic hash.  There is no way for git to put this information into
>>> the file in a meaningful way, because even if it just stuck the hash into
>>> the file where you told it to, you still need the rest of the repository
>>> in order to determine whether one particular hash is more recent than
>>> another.  The hashes by themselves don't tell you anything about the age
>>> of the file, so if you want a version number in the file header, you still
>>> need an external script to determine what that version number should be,
>>> so it makes sense to have that script do the substitution, rather than put
>>> that functionality into git.
>> Ahhh - ok, I see the miscommunication here. I'm not talking about
>> specifically about a file/module. We all know software is comprised of a
>> lot of different modules. I'm not a GIT person (yet) - I know SVN
>> better. What I'm talking about is "tags" which do stay consistent.
>> You'll tag a collection of files at given revisions to belong to the
>> same "release" which is what makes sense when you do your RPM builds and
>> your final code release.
>>
>> You'll get no argument from me, that during distributed development,
>> version numbers make little sense. I love the SVN concept of revision
>> numbers that just count up. That makes more sense than the artificial
>> 1.2.3.4 numbers/letters on individual files. That construct is
>> artificial anyway, and hence the TAG.
>>
>> In other words - I do see the need to be able to query the metadata on
>> build. Of course you can just change a constant yourself and check it
>> in. It would have the same programmable effect - but you wouldn't have a
>> sync/link to the version control.
>>
>> --
>> Best Regards
>>   Peter Larsen
>>
>> Wise words of the day:
>> "A power so great, it can only be used for Good or Evil!"
>>                 -- Firesign Theatre, "The Giant Rat of Summatra"
>> _______________________________________________
>> Novalug mailing list
>> Novalug@calypso.tux.org
>> http://calypso.tux.org/mailman/listinfo/novalug
>>
>
>




More information about the Novalug mailing list