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

greg pryzby greg@pryzby.org
Tue May 31 18:43:31 EDT 2011


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
>



-- 
greg pryzby                              greg at pryzby dot org
http://www.linkedin.com/in/gpryzby

WEB:  http://www.RestonArtisTree.com/
TWTR: gpryzby



More information about the Novalug mailing list