JSPWiki: SimpleVersionControl

At line 0 added 55 lines.

+ <pointless-analogy>

+ I guess it's like walking along a plank of wood. It's not such a big deal - you just walk along in your own time. I bet you could do it twenty times over with no effort. But if this same piece of wood was balanced between two high buildings with a large drop below, it would suddenly seem a lot more difficult.

+ </pointless-analogy>

+

+ However, this safety net is rarely actually used - well, not enough to warrant all the pain staking commands that have to be executed daily to work with your version control system. Having to constantly add and remove files is tough work to remember and can disrupt the train of thought. And then many systems have annoyancies like not being able to rename a file without having to remove the old one and add the new one - renaming a directory is even more interesting.

+

+ So the best of both worlds seems to be a system that allows us to revert to earlier versions but is completely transparent to work with on a day to day basis. All we need really is a sense of security.

+

+ We started chatting about this at XtC20020305 and came to the conclusion that the simplest thing to use would be a shared file system that would detect files being saved and automatically create a new version in the repository. Apparently [http://www.starbase.com/products/starteam/ StarTeam], [http://www.rational.com/products/clearquest/ Rational ClearCase] and [http://www.netcraft.com.au/geoffrey/katie/ Katie] do this. This sounds great, but something inside me is nagging saying there's a simpler approach.

+

+ Many IDEs have very good version control integration, so file operation you perform inside them will result in the correct version control commands being executed. This also is a great solution, but falls down a bit when file manipulation takes place outside of the IDE (and it always does at some point).

+

+ TeamStreams has cropped up a few times and it sounds like a perfect solution. From what I can gather, you have 2 main commands - update and commit (or whatever the equivalents are). That sounds headacheless to me. Unfortunately, TeamStreams seems to be something I can't get my hands on - please help if you know of a way to get at it (without having to switch IDEs).

+

+ So, I need a solution. It needs to be as transparent as possible, low-risk, simple to use and shouldn't be too tricky to implement.

+

+ --JoeW

+

+ I have this problem too, and even ranted at Martin Fowler for a bit at XPDay 2001 about how current version control systems are not a good match for XP. I am not a great fan of a version control system built into an IDE, as it effectively requires all users (and all machines) to use the same IDE. This independence is one of the reasons for the great success of CVS and its predecessors.

+

+ The main problem I have is that all the VC systems I have used treat the ''file''

+ as the unit of change rather than the ''project'', and this is a very bad fit for a methodology which

+ encourages free refactoring, especially in a language (such as Java) where files and filenames are syntactically important. CVS doesn't require me to tell it that I have added or changed a particular line in a file, so why should it require me to tell it that I have added or changed a particular file in a project?

+

+ The nature of my work is that I do a lot of work on my own, but from multiple locations, using several different machines. What I would dearly love is a VC system which gives me the following, simple options:

+

+ 0. tell it who I am, so it knows about me, and what I'm working on

+ 1. open the current source of a project (either the main line of development, or a line I was working on but had to save in an unstable state) to begin making changes.

+ 2. snapshot an in-progress set of changes for use from another location or machine, or at a later time.

+ 3. abandon a any changes and re-fetch the main line or a named previous version if I feel I have screwed up.

+ 4. close a completed set of changes to the main line, resolving conflicts and adding a version name, release comment etc. if necessary.

+ 5. deliver (either the latest main line, or a named previous release) to the customer.

+

+ A command line or direct-call API for the above should be as simple as:

+

+ 0. connect <project-server-name>

+ 1. record

+ 2. pause

+ 3. rewind { <optional-version> }

+ 4. stop

+ 5. play { <optional-version> }

+

+ Sorry for the stretched metaphor, but I hope you get the point, and I bet you could imagine the icons :)

+

+ Everything else, the system should know. If I make a new file or directory in the workspace, ensure it is booked in on a "pause" or a "stop". If I delete or rename a file or directory, make sure that the paused or stopped project cotains no reference to the old one any more.

+

+ I would love to hear of a VC system which offers this sort of simplicity. I can't see any unsurmountable technical problems, but I have also never seen one as easy to work with as this, so there must be some reason, even if it's just my own lack of research ...

+ --FrankCarver

+

+ See http://www.linuxmafia.com/~rick/linux-info/scm.html for a comprehensive listing of source control systems and http://better-scm.berlios.de/comparison/comparison.html for a detailed feature comparison.

+

+ Most of the fancier version control systems (clearcase, bitkeeper, aegis, arch, etc) have moved over to the notion that you have a set of changes which form a unit of work and it's the version control system's job to manage these (and definitely not files or folders). More changeset related info is available here:

+ * http://minnow.cc.gatech.edu/squeak/674

+ * http://regexps.srparish.net/tutorial-tla/changeset-format.html

+