Summary
Perhaps we only commit big chunks at a time as an artifact of older version control systems. What if we treated it as a full-fledged undo facility?
Advertisement
Imagine if everything you did was undoable all the time, similar to what the Macintosh time machine produces -- it's just keeping track of everything in the background and if you need to change something you just back up.
Right now we have to make decisions about what and when we commit. But what if you didn't have to?
Also, if everything was being tracked, as in an undo facility, you could say things like "lets zero in on where the most activity was taking place during a certain time." This might even be able to detect patterns of behavior during programming.
Of course, such a facility would require very strong coupling between the editing environment and the cloud where the information was being kept.
It seems pretty obvious that's where we'll eventually go, complete versioning built into the file system - probably with a meta-data structure. I mean, why should we let ourselves be bound to the typical hierarchical organization of things as we are today. If I downloaded a music item, say "Regina Spektor - The Call", I want to be able to save it both in the folder "Soundtracks", "Singer-songwriter" and "Regina Spektor" (rather than having to provide tags inside the file and rely on desktop indexing/search).
But as always, some things are so revolutionary different that it can't fit into the current model. How do we show a standard save-file dialog with these features enabled? For that you need it build into the OS which is what was so promising about WinFS Microsoft sadly ended up dumping.
So these features seems most likely to come from Apple or Linux where revolution can be chosen over evolution.
The metaphor works well in the single user scenario but breaks down in a multi-user situation. In a multi-user environment, version control is also about consistency between commited changes and isolation between developers.
I started using Eclipse about a year ago and was delighted to discover that eclipse saves a checkpoint of each file every time you save (you can configure how long too keep each file's history and how much disk space to limit it to). You can browse each file's history, view diffs and bring patch-wise changes back from the past. It really is similar to committing each time you save.
That feature has certainly saved me on several occasions. The one major difference between this and 'commit' is that when you commit your changes you're basically saying something about the state of the entire project -- that all those changes make a single checkpoint and there's usually a concise summary (commit message) about that checkpoint. With Eclipse's local history feature each file has it's own individual history. But still, it's a pretty great feature.
> The metaphor works well in the single user scenario but > breaks down in a multi-user situation. In a multi-user > environment, version control is also about consistency > between commited changes and isolation between > developers. > > I would say version control is ACID.
If you use a distributed version control system that isn't really an issue. You can do all the commits you like to your local repository, and then make a big commit to the main repository when you are ready.
> The metaphor works well in the single user scenario but > breaks down in a multi-user situation. In a multi-user > environment, version control is also about consistency > between commited changes and isolation between > developers.
Yes, with multiple users accessing the same files on a single system, this could make things complicated. However, for me the upside of a versioned file system would out way the limitations.
With distributed systems like Git and the like, it's definitely the case. Unfortunately support for git outside the Linux and command-line areas is not so good :)
I do however use time-machine as undo *all the time*. When I'm about to do something potentially unpleasant to a project and don't want to commit what I have at the moment to SVN, I'll force a time-machine backup and make a note of the time in stickies. Works a treat.
IntelliJ has suppprt for Git. Also I have been using its local history for quite a while, which has a number of events that cause a snapshot to be taken, such as running a unit test, saving, refactoring...
ZFS snapshots on the file system work in much the same way (in terms of being able to undo things) - but perhaps in not an 'easy' way. However, they do give transparent ability to roll forward (and importantly, roll back) completely between updates.
Honestly, I think this a bunch of nonsense. Even with version control as it is used normally, Finding a specific set of versioned files is like searching for a needle in a haystack in moderate-sized or large-sized team. A version control repository without labeled versions is less valuable than one with labeled versions. Adding more versions to the repository without any intelligence devalues the repository.
As the above posters point out, there are already many ways that developers can keep track of every change they have made. Distributed VCS seems to add an extra layer of indirection that provides much more value than an glorified undo.
I like the idea of unlimited undo, but I think you also need a commit option. If the unlimited undo can be limited to what I see and the commit makes my changes visible to the team (and the continuous integration server) then I think we will be at version control nirvana.
Think for a moment. Do you really want someone to "detect patterns of [your] behavior during programming"? Who is doing the detecting? Do you want someone to know that you use global variables all over the place until you understand the problem better? Do you want someone indexing the swear words you use as function names until you come up with better ones? Do you want someone sifting through your thoughts and dreams?
Call me paranoid, but some things are suitable for public consumption and some things are not. Oh, that's right. Everyone does pair programming nowadays. Hence your pre-commit programming practices are already witnessed by at least another set of eyeballs.
:-/
Jon's onto something: "commit makes my changes visible to the team" (emphasis added).
> Jon's onto something: "commit makes my changes visible > to the team" (emphasis added).
Agreed, however the path to my perfect change isn't always straight, so being able to manage micro changes and branches locally is very useful.
It is often complained that published mathematics takes the original logic and then erases steps until the derivation can just barely be discerned. It is the way the game is played, but should it be that way? Similarly how much of our micro changes should be erased when committing?
My employer already has the ability to watch these sorts of things, simply by installing a keylogger. The only reason they DON'T is social. So this sort of ability just makes it easier for ME to retrieve old information. It might also make me more confident about deleting stuff when I think it's worth rewriting.
Besides, I honestly wouldn't mind if my employer DID monitor my coding behavior. The main complaint they would have is that I apparently only spend about 10% of my time coding and all the rest is spent in meetings or interruptions -- and I've been trying for YEARS to get them to realize this!
Flat View: This topic has 83 replies
on 6 pages
[
123456
|
»
]
Previous Topic
