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

James Ewing Cottrell 3rd JECottrell3@Comcast.NET
Thu Jun 2 12:40:55 EDT 2011


  On 6/2/2011 8:41 AM, Peter Larsen wrote:
> On Wed, 2011-06-01 at 14:56 -0400, James Ewing Cottrell 3rd wrote:
>> You don't have to be...you'd be the One Eyed Man in the Kingdom of the
>> Blind.
> You know - top posting is just as easily frowned upon as ....
Thank You Allan.
>> Besides...I'm thinking that some of the features that Linus is
>> Championing are actually Bad...such as the ability to Rewrite the
>> History. Clearly, the Ministry of Truth uses git ;-)
> WHAT?? You cannot be allowed to disagree with the big mighty Linus
> T. ... don't you know that his word is (linux) law? *smile*
Doh! I'm Ugly and Stupid!
> Actually, GIT doesn't rewrite history. This whole thing is a matter of
> where you keep the matter of record. And I for one can easily do without
> the mile log "history" and "author this" at the top of every file.
Not the sprawling $Log$ messages...but in git it is possible to change a 
repo to edit the sequence of commits. And I am not talking about 
Rebasing...I mean you can undo commits and pretend they never happened.

I can see the utility in removing unwanted items from the repo, like 
Huge Tracts or Powerpoint tho.
>> OK, back to the original discussion. While it would seem that Keywords
>> do indeed have less meaning when there is more than one repo, files DO
>> exist outside of the repos,
> No - if you depend on "outside the repo" things, your repo is at fault.
I would expect to have many copies of a given file and one repo.
> Someone else correctly pointed out that the repos consist of more than
> software. We should use version control for everything, including
> configuration, metadata and library references (to mention a few).
I said that in a separate message. Thank You Brother.
>> and it's often quite useful to examine the
>> date. Of course there are Tags that are unique, but so are the
>> Change-IDs.
> Sure! And sometimes the change history too. That's all in the
> repository. It's a "git" away. Using a IDE which is GIT/SVN aware, you
> can actually see this data right with the file as you view it.
I am talking about comparing files *after* we have checked them out. 
Which version do I have on node1 vs node 2? I can look at the content, 
but a Last Revision Date and Recent Revision List would help greatly.
>> And indeed, an abbreviated
>> list of the most recent changes could be stamped on a file. I wouldn't
>> mind seeing something like:
> That is in effect what git does. The data is associated with the file
> and viewable quite easily. It serves little purpose to put redundant
> data inside the actual source you're trying to manage.
Yes, but I am talking about the Files after they have been Checked Out 
of Git.
>> $Git: 3141-5926-5358-9793-2384-6abc-dead-beef-face-0000$
>>
>> That string should be (assuming identical formatting) unique, no?
> That number/ID is nonsense. It doesn't tell you anything.
Of course it does! And it's Unique. OK...assuming that the number on the 
left is the most recent one...which file is newer...pick Line 1 or Line 2...

[1] $Git: 2718-2818-3141-5926-5358-9793-2384-6abc-dead-beef$
[2] $Git: 3141-5926-5358-9793-2384-6abc-dead-beef-face-0000$

At this point, I may not care WHAT the differences are...I just know 
that at some point, I wanted the E modifications to the PI file. I can 
investigate if I need to.

Now you might argue that I could just check out a new version...but each 
might also have local modifications
>   In a shared
> development environment it may increase quite often without impacting
> what you do. It's not that there is a change, but WHAT changed, that
> matters. What I want to know as a developer, may also be different than
> a package maintainer wants to know, or a QA person. All in all, we have
> all of the needed information right at our fingertips - in svn,git,cvs
> etc.
Not always. Most of the time we apply changes blindly, trusting that the 
maintainers know what they are doing. Your focus is as a 
Developer...cherry-picking specific patches and feature. Mine is more 
from a SA point of view...where files have been checked out of one or 
more repos, possibly at different times, and we can't remember exactly 
what we did where or when, and trying to figure out what's what.

My Bottom Line Point: while Revision Keyword Expansion is not as 
important as it used to be...it is NOT meaningless. Files should be 
Stamped with The Best Possible Information available, even if that 
information is Not Perfect. I want some way of matching up the File to 
the Repo.

JIM



More information about the Novalug mailing list