Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

History of version control - 10 astonishments

flourish.org

Post reply on HN
Print view View original

61–70 of 76 posts

Re: History of version control - 10 astonishments

#61

Post by viraptor »

gbog wrote: post #57
viraptor wrote: post #50

Earlier quoted context omitted.

This should be much simpler once we stop using those silly text files and start storing everything as a proper representation of AST. Then again, at that point we can get rid of the silly text-diff-based systems and just store everything as versioned trees.

This sounds like a bad idea. Code is text. If ast helps merging diffs, why not use it for analysis in case of conflict and keep code as text?

Because you can always convert from ast to text, but not always from text to ast. Also it's easier and faster to convert ast->text, and you can do it when needed only. Additionally you'd never commit a syntax error. Why is it a bad idea?

Re: History of version control - 10 astonishments

#62

Post by tikhonj »

wglb wrote: post #23
sehugg wrote: post #22

Ugh, SourceSafe. I worked for a company that used it. They had terrible intermittent file corruption issues. Long story short, we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick, which caused network errors over SMB which led to file corruption. Ugh.

I used SourceSafe for the better part of 10 years. The underpinning technology very much resembled RCS. But all-in-all, it was quite serviceable for a 75,000 line C++ project. Just don't try to do branches.

That's a little bit like saying "All-in-all, this car is quite serviceable. Just don't try to use third gear."

Re: History of version control - 10 astonishments

#63

Post by tikhonj »

gbog wrote: post #57
viraptor wrote: post #50

Earlier quoted context omitted.

This should be much simpler once we stop using those silly text files and start storing everything as a proper representation of AST. Then again, at that point we can get rid of the silly text-diff-based systems and just store everything as versioned trees.

This sounds like a bad idea. Code is text. If ast helps merging diffs, why not use it for analysis in case of conflict and keep code as text?

I think it's most accurate to say that code is a textual representation of an AST. Saying that it's just text is just like saying it's just a bunch of numbers--both technically true but missing the bigger picture.

One potential reason no to store code as text is that there are many equivalent programs that differ only in inconsequential text. A perfect example is trailing whitespace.

There are also some benefits of storing code as an AST. For one, it would make it trivial to identify commits that did not change the actual code--things like updated comments. This would help you filter out commits when looking for bugs. Another benefit would be better organized historical data: in a perfect system, you would be able to look at the progress of a function even if it got renamed part of the way through.

Re: History of version control - 10 astonishments

#64

Post by tikhonj »

viraptor wrote: post #50
sendos wrote: post #45

It makes me wonder, what is next? What new astonishing thing will happen in version control? I think what's needed is an intelligent (as in AI) merge mechanism. Right now, if two people are adding two different features to a set of files, then merging those changes is error-prone and requires a lot of manual work. If this ever gets perfected and automated, it will be a huge milestone.

This should be much simpler once we stop using those silly text files and start storing everything as a proper representation of AST. Then again, at that point we can get rid of the silly text-diff-based systems and just store everything as versioned trees.

I actually wrote a very simple system like this for a hackathon several months ago. The idea is that we would take some basic Scheme code (boy did we aim high :), parse it and commit the result. We would then diff the trees and keep track of the changes that way. Finally we had a cute web front-end that pretty printed the code from the AST and could show the diffs visually.

We got the basics working, including simple diffs. One goal was to link the same variables between two versions; we did not manage to make that work, but had a very hacky approach that looked like it worked.

Doing any sort of merging with this data is nontrivial. We were planning to implement it, but unfortunately ran out of time. Still, we did have a cute demo of some commits and some diffs in the end--it actually worked a little, which is much more than I expected starting out.

However, despite not implementing merging, we did throw in some nice features. Particularly, we were able to identify commits that did not change the function of the code (whitespace and comment changes only) and mark them. This was very easy but yet still useful, and a good indicator of the sorts of things one could do with a system like that.

After the hackathon, one of my friends found some papers about a system just like ours. I don't remember where they were from, but if you're interested you could look for them. (I think the phrase "semantic version control" is good for Googling; that's what we called our project.)

Overall I think that it's a neat domain but in hindsight maybe it was a little too much for 18 hours of coding :) We did have fun, and it was cool, so I have no regrets.

Re: History of version control - 10 astonishments

#66

Post by adambyrtek »

tikhonj wrote: post #63
gbog wrote: post #57

Earlier quoted context omitted.

This sounds like a bad idea. Code is text. If ast helps merging diffs, why not use it for analysis in case of conflict and keep code as text?

I think it's most accurate to say that code is a textual representation of an AST. Saying that it's just text is just like saying it's just a bunch of numbers--both technically true but missing the bigger picture. One potential reason no to store code as text is that there are many equivalent programs that differ only in inconsequential text. A perfect example is trailing whitespace. There are also some benefits of s…

But then you end up with a version control system that is not generic, but dependent on a particular language. The story of Smalltalk suggests that the added value might not be worth the coupling and complexity it requires.

Re: History of version control - 10 astonishments

#67

Post by kbutler »

gbog wrote: post #58
InclinedPlane wrote: post #43

It's easy to forget that we are living in a golden age of version control systems. The market is rife with many fairly decent commercial systems and some of the best, state-of-the-art systems are completely free.

Sorry to not share your angelism. git seems worshipped here. I never used it but I used cvs and mercurial a lot, and we are very far from what a real,versioning should be: completely transparent. cd dir should propose to update it. save file should commit it and push it in tmp branch.

I do wonder about transparent persistence & versioning - bring on the unlimited undo, independent of editor processes. This would require a better interface for navigating the history than undo/redo or git log. Time Machine is an exploration in this direction.

"Save" can tag a state as interesting.

But please don't conflate "cd" and "update" - I rarely cd (emacs), but I really don't want to grab partial changes from other branches just because I'm working in a directory. Notification that a file has been changed in other commits would be fine, but "a directory" is a poor heuristic for unit-of-change.

Re: History of version control - 10 astonishments

#68

Post by to3m »

rue wrote: post #54
to3m wrote: post #46

Earlier quoted context omitted.

If you ignore all the distributed "stuff", and the workflow enhancements it permits, and assume everybody is always connected to the server and attached via a LAN, you can just concentrate on doing a reasonably good job of handling very large quantities of data, including very large binary files. (Apologies for not trying to reproduce the breathless style of headline.) As is common, the article presupposes that decen…

> As is common, the article presupposes that decentralization is unambiguously progress, but that isn't true in all respects. It is, in the sense that a decentralized VCS is, essentially, a superset of a centralized one. … Blobs are certainly still an issue, though orthogonal to distribution (I don't think you intended to imply it was related, but it could be read as if you did).

Well, I don't mean to imply that binary files are inherently impossible to handle using a decentralized system. In fact, I have some PDFs and PNGs in my git repository, and git has managed not to make a mess of them. But I still think binary files are difficult for distributed systems to support well.

Distributed systems rely on allowing people to (in effect) create multiple versions of the same file, and then merge them all together later. But it's very rare that binary files are mergeable! And if the file can't be merged, the distributed approach won't work. People will step on one another's changes by accident, and people will have to redo work.

The usual solution is simply not to allow multiple versions to exist: enforce some kind of locking system, so that each editor has to commit their changes before the next one can have a go. But now you need some centralized place to store the locking information...

Re: History of version control - 10 astonishments

#69

Post by latchkey »

kisielk wrote: post #59
latchkey wrote: post #29

It is interesting to me that Subversion barely gets a mention. There should be a 7.5 which is along the lines of: cvs was great and all, but we couldn't version our directories, branching and merging was a mess, the wire protocol was hard to use, it had a ton of security holes and the storage format took up too much space. So, Subversion was created as a way to do a better cvs, without thinking about the larger intri…

With Subversion branching and merging was still a mess, at least everywhere I ever saw it used.

Oh, it is a complete failure. I've switched to Git entirely as a result of it and will never use Subversion again if I can help it.

I wrote a long'ish blog post detailing why it is a failure:

http://lookfirst.com/2011/04/subversion-mistake.html

Re: History of version control - 10 astonishments

#70

Post by tikhonj »

adambyrtek wrote: post #66
tikhonj wrote: post #63

Earlier quoted context omitted.

I think it's most accurate to say that code is a textual representation of an AST. Saying that it's just text is just like saying it's just a bunch of numbers--both technically true but missing the bigger picture. One potential reason no to store code as text is that there are many equivalent programs that differ only in inconsequential text. A perfect example is trailing whitespace. There are also some benefits of s…

But then you end up with a version control system that is not generic, but dependent on a particular language. The story of Smalltalk suggests that the added value might not be worth the coupling and complexity it requires.

You should be able to write a generic version control system like this where you can just plug the appropriate parser in and it would work for that language. For backup, you could have it still keep some files as text.
Post reply on HN