The Artima Developer Community
Sponsored Link

Weblogs Forum
Version Control is Undo

83 replies on 6 pages. Most recent reply: Jan 27, 2009 7:17 AM by Dhruva Krishnamurthy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 83 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]
Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Version Control is Undo Posted: Nov 26, 2008 3:28 PM
Reply to this message Reply
Advertisement
> Jon's onto something: "commit makes my changes visible
> to the team
" (emphasis added).

With distributed SCM you can commit without your team mates seeing the changes until you push to the main repository.

If you're really paranoid about people seeing your incremental changes, you can work around that by never pushing your working branch, but rather just generating patches from it, applying them to the main branch, and then pushing that.

Jon Strayer

Posts: 10
Nickname: jstrayer
Registered: Sep, 2003

Re: Version Control is Undo Posted: Nov 26, 2008 6:05 PM
Reply to this message Reply
> Similarly how much of our micro changes should be erased
> when committing?

That's an excellent point. I'm not sure I'd want to be the one to implement it, but I like the idea. :-)

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: Version Control is Undo Posted: Nov 26, 2008 9:16 PM
Reply to this message Reply
Hmmm. I don't think I have to be truly paranoid to feel uneasy about Bruce's idea. Nor do I need to be afraid of an employer, or be trying to prove something about time wasters.

Pretend we live in the not-too-distant future. Pretend I participate in a project in Google Code. Pretend I use a Google web app for my editing. Pretend I have a habit of temporarily naming stuff after W.C. Fields characters and locutions. Next thing I know, I'm seeing ads right and left--even on devices that I haven't used for programming--for Fields stuff.

If everything were being tracked, people with access would have more data to use for their own purposes and come at me with their findings. Whether it's a pay-per-view service trying to get me to watch "International House" complete with "the making of" and the latest expert commentary. Or an employer apologizing every other day for how much of my time gets wasted. Or someone proving that 80% of spelling errors in code are committed by 20% of developers between 4 and 8 p.m. local time. Or you name it.

No, I don't need to be paranoid, I just need to be a loner. Make it stop, already. I vant to be left alone.

Bob Lauer

Posts: 5
Nickname: rfl4711
Registered: Jul, 2008

Re: Version Control is Undo Posted: Nov 27, 2008 7:25 AM
Reply to this message Reply
"I mean file systems, how qaint, how seventies ..."
-- Kent Beck

:-)

Dale Nagata

Posts: 2
Nickname: dnagata
Registered: Jan, 2006

Re: Version Control is Undo Posted: Nov 28, 2008 11:58 AM
Reply to this message Reply
> It seems pretty obvious where we'll eventually go,
> complete versioning built into the file system

everything old is new again

> "I mean file systems, how quaint, how seventies ..."
> -- Kent Beck

that seventies file system used by VMS had versioning built-in. came in handy for files not under version control
(e.g. the VAX equivalent of /etc config files and startup scripts etc)

still haven't seen any file system since with that.
(not counting ClearCase MVFS extension)

bug not

Posts: 16
Nickname: bugmenot2
Registered: May, 2005

Re: Version Control is Undo Posted: Nov 29, 2008 1:07 AM
Reply to this message Reply
Well I used one such system back in the Smalltalk days called ENVY (actually VisualAge for Java had it too!). It kept track of all changes and had a very good system to manage all those changes and merge them in a team environment.

Alas.. I think such ideas are way above the head of mainstream file based programmers. Some even think that Ruby is innovative.. and that "closures" are a new idea in OO. One day we'll catch up w/the 70s-80s research.

Waiting to see some really new ideas.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Version Control is Undo Posted: Nov 29, 2008 4:00 AM
Reply to this message Reply
> still haven't seen any file system since with that.
> (not counting ClearCase MVFS extension)

NTFS in Vista has the capability to restore previous versions. You can use ZFS to achieve something similar as with this approach: http://alblue.blogspot.com/2008/11/crontab-generated-zfs-snapshots.html

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: Version Control is Undo Posted: Dec 1, 2008 2:33 AM
Reply to this message Reply
do that in many companies and you end up breaking automatic builds, and you may end up loosing your job...

Someone sees incomplete code in version control, freaks out over the way it looks, and accuses you of producing poor quality.
Bye bye career.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: Version Control is Undo . . . or more Posted: Dec 3, 2008 10:30 AM
Reply to this message Reply
This, what might be called 'extreme-versioning', is notable, but it doesn't change the basic activity. To do that, some logical structure has to be changed or added.

What would be more interesting (but more demanding) would be a syntactical modularising of the versions -- ie: the changes are well-defined according to the language. That adds some new logical structure. Then perhaps manipulations like merges could become like an extra dimension of compilation . . .

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Version Control is Undo . . . or more Posted: Dec 3, 2008 8:14 PM
Reply to this message Reply
A good IDE e.g., IntelliJ IDEA, has it's own local history facility just for this purpose. You want to look at what changes you've made and possibly undo them without adversely affecting the system of record? Local history is the tool.

Regarding source control, the concept of incremental undo is not so useful, even if serving only one dev. Why would you want untested changes entering into central source control? Auto builds will crash, auto testing is for naught, change history is polluted, etc.

Harrison Ainsworth has touches on what may be a killer development tool. Imo, it goes beyond language-aware source control. It will be a wonderful day when the programming language, IDE, and source control work in concert to provide a truly intelligent development system.

A few examples:

- The programming language would not persist in a textual format -- we are beyond the benefit of ascii
- Provided the language is statically typed, analysis tools could be extremely powerful and relatively simple to write
- Refactoring becomes a natural part of the IDE e.g., you change the name of a field and it automatically changes everywhere it's used as you type (because all the references to the field point to the field)
- Code completion would become scary intelligent
- Code formatting becomes a non-issue
- Changes made to a type that are logically and structurally equivalent are inherently discoverable by source control

I recall seeing a language and system with some of these characteristics a while back from a Microsoft research project, but I do not recall its name...

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Version Control is Undo . . . or more Posted: Dec 4, 2008 3:51 AM
Reply to this message Reply
> A good IDE e.g., IntelliJ IDEA, has it's own local
> history
facility just for this purpose. You want to

I find that IDEA's local history gives a rather poor view of changes affecting more than one file. A regular commit into something like Mercurial gives a much better view of activity, even if the commit message consists of nothing more than the date/time.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 4, 2008 10:43 AM
Reply to this message Reply
> - The programming language would not persist in a textual
> format -- we are beyond the benefit of ascii

Sorry but I won't use it if there's not a plain text representation of the code. Every tool that I've ever used that didn't use text as it's canonical representation has created a maintenance nightmare. There is a lot to be said for being able to read the source without special tools even if you rarely need to do so. Maybe there are ways to avoid the issues I've run into in the past but it would take a lot of convincing to sell me on this.

And really, what's the problem with using text anyway? It seems like change for the sake of change.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Version Control is Undo . . . or more Posted: Dec 4, 2008 10:50 AM
Reply to this message Reply
> And really, what's the problem with using text anyway? It
> seems like change for the sake of change.

The comments for some of my code could benefit from embedded diagrams and mathematical formula. While I could embed (La)TeX in the existing text, for most readers today that would be as cryptic as the code (or even more so).

I could alternatively write twenty lines of text and it would still not be as clear as the simple diagram done with pencil on my paper notes. Unfortunately that diagram doesn't get checked in, so most readers of my code won't see it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 4, 2008 2:05 PM
Reply to this message Reply
> > And really, what's the problem with using text anyway?
> It
> > seems like change for the sake of change.
>
> The comments for some of my code could benefit from
> embedded diagrams and mathematical formula. While I could
> embed (La)TeX in the existing text, for most readers today
> that would be as cryptic as the code (or even more so).
>
> I could alternatively write twenty lines of text and it
> would still not be as clear as the simple diagram done
> with pencil on my paper notes. Unfortunately that diagram
> doesn't get checked in, so most readers of my code won't
> see it.

I don't see any reason why having the code in text means you can't have external resources that reference the text. Yes, you wouldn't see the comments in the code when you looked at the raw text but it's not really about making the text easy to work from, per-se.

I am not arguing that more advanced tools can be created to make coding more efficient and powerful, I just don't think that eliminating readable text as the native format for the code is a prerequisite.

For example, I was looking at some stuff on projects to take Java code and persist it into the database. If you can take the code and automatically do this, then it's clear that the code has as much information as the database.

It's one thing if you can present something that can't be done (well) with text as you have done but to say that everything will be better once we get away from text is not supported by my experience with tools where code is persisted in databases or arcane binary formats. If languages do move that way, I predict the same issues will present themselves in a number of tools.

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Version Control is Undo . . . or more Posted: Dec 4, 2008 8:38 PM
Reply to this message Reply
James, I understand your concern. I also agree that it's not absolutely necessary to move away from text in order to provide a truly integrated dev environment; IDEA is an amazing tool as are others. But as I see it the benefits of text diminish given the dev tools we use are hampered by that format -- analysis, search, refactor, code completion, etc. all depend on type information, not text. Essentially, the primary reason to stay with text is so we can use source control to manage and track changes. So my point is if source control could be integrated with the language elements and not text (a good thing!), why bother with text?

Take IntelliJ IDEA. Think of all the antics it goes through to essentially synchronize the textual representation with the parsed model it maintains. Two SORs usually indicates a bad design, and since the text is obviously not nearly as efficient or as dense as the model, the logical choice is to scrap the text. Sadly, we can't do that until we have a truly integrated source control system.

Of course, as humans we need the text, and the IDE can still give it to us and present it just the we like it. All while providing a larger set of more efficient tools! So it's not an either-or proposition, as you've pointed out.

I must admit I do have an appreciation for good old text; it's simple and accessible. But as I've pointed in the best of worlds the actual benefit of text in our day to day work is quite limited.

Flat View: This topic has 83 replies on 6 pages [ « | 1  2  3  4  5  6 | » ]
Topic: Report on an Unconference in Poland Previous Topic   Next Topic Topic: The Demise of the Headhunter


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us