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

Peter Larsen plarsen@famlarsen.homelinux.com
Thu Jun 2 14:45:19 EDT 2011


On Thu, 2011-06-02 at 12:40 -0400, James Ewing Cottrell 3rd wrote:
> 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!

Always careful of criticizing the linux gods ... I mean, DUH! Well, at
least in public ... :)

> > 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.

Given GIT is not a central database, that's only natural? But removing a
revision also removes the code so you're not "changing history" by
denying someone his/hers accreditation - you either include his/her work
or you don't. I think it's highly philosophical if someone who's work is
no longer present in the code, should be on the accreditation list.

> I can see the utility in removing unwanted items from the repo, like 
> Huge Tracts or Powerpoint tho.

Now those kinds of files I haven't seen included yet but I have dealt
with large binary files. That's a hazzle because they take up a lot of
space in the repo for every checkin and you can't really track the
changes to them.

> >> 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.

That's logically what the repo is all about? You have the same file in
the repo in many different versions inside the repo. Sometimes you even
have "copies" of the same files in multiple locations such as when you
tag something. The fact that the repo actually doesn't contain full
copies of the file over and over again, is a different talk I guess.

> > 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.

Glad we agree.

> >> 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. 

Sure? I do that all the time? I hit "compare to current version" and I
get a niiice split screen that shows me every difference (if any) based
on the version/revision I picked. Default is the one I checked out, but
I can refresh my local repo, and compare against any revision, include
new ones checked in while I was editing. Now, with SVN and in particular
CVS that wasn't possible. This is why you had "SVN hitler" walk around
to developers every Friday telling to "check in or else ....".

> Which version do I have on node1 vs node 2? 

If you have a local copy it's not a local version/revision yet. There's
a simple command to make sure that your local copy is at sync with the
repo. If you haven't done any changes, you're really best served by
syncing before you start your work. In other words, there's really no
reason to check that.

If you have multiple repos - and with GIT you have those - it's an easy
thing to connect to both and compare them. My simple GIT plug-in for
Eclipse does that pretty easily. I can even click on the files to view
them, or view the exact changes between two revisions (in the same
repo). Each system will know, again by a simple git query, which
revision was checked out.

A long way of saying that knowing what you have is easily done through
the source control metadata queries. There's no need to have that put
into the file.

> I can look at the content, 
> but a Last Revision Date and Recent Revision List would help greatly.

When I open any file in an IDE I get little property windows on the side
that gives me all that data. Revision numbers can even be displayed as
part of the navigation tree. All because that information is there
already. It would be redundant putting it into the actual checked in
file. This was really Linus' point - and in that I agree with him.

> >> 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 

No difference. Git/svn/cvs knows what you checked out. Ask it.

> >> 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$

Still nonsense. If I have no changes to my code, I refresh it from the
repo before I start any edits. Once I start edits, I owe it to the rest
of my team to check the file in as soon as I can with the changes I've
made. Knowing that a file has changed since the check-in is again
straight forward?

> 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.

You're basically doing what SVN/GIT does for you automatically? Ask it
to update your files. It'll gladly tell you if it finds you've messed
with files and if you want them overwritten with the current latest
version or if you want to keep your altered copy.

Best practices to me (with SVN) has always been to only check out when I
had to do actual changes, do the changes and within that day or hour
check the changes back in. That's of course not always possible; but
keeping a file checked out for days or weeks is even worse. That should
not happen.

> Now you might argue that I could just check out a new version...but each 
> might also have local modifications

You'll be told and warned if you try to check out and overwrite local
changes made. I'm usually only interested in the changes done - not IF
there were changes (I can see that). And that's a click or two away in
my IDE. The bottom line again is, that I don't need anything INSIDE the
file to know this.

> >   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.

Mixing and matching repos is something I'm not familiar with. I've heard
gruesome rumors that GIT allows you to do that - if so it lost some of
my support. Within a project I would not want "half in git1 and the
other in git2". 

To know if there are any changes, you have "git diff" and "git status".
I just made a very small git repo here, changed a file and wrote "git
status". Here's from the output:

modified: src/.../helloworld/MyJMSListenerAction.java

It's what you wanted to know right? Now I can take action. It even tells
me all kinds of other stuff like what I haven't checked in yet, missing
from the tree and much more.

> My Bottom Line Point: while Revision Keyword Expansion is not as 
> important as it used to be...it is NOT meaningless. 

The revision number itself is not. Putting it inside the file you are
describing with the revision, is. It's like having a collection, where
the content of the "top" of the collection points to the collection. You
already have a collection manager - there's no need to include that in
the members of the collection.

> Files should be 
> Stamped with The Best Possible Information available, even if that 
> information is Not Perfect. 

Why? I get the perfect information directly from the repo every time.
Why settle for less?

> I want some way of matching up the File to 
> the Repo.

You have that. See above.

-- 
Best Regards
  Peter Larsen

Wise words of the day:
What if everything is an illusion and nothing exists?  In that case, I
definitely overpaid for my carpet.
		-- Woody Allen, "Without Feathers"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.firemountain.net/pipermail/novalug/attachments/20110602/2e4b7efa/attachment.asc>


More information about the Novalug mailing list