Slashdot Mirror
Designing a New Version Control System?
tekvov asks: "When Linus Torvalds decided to use BitKeeper as the version control system for Linux there seemed to be a lot of controversy and many challenges to create a better system than CVS. My question is exactly what would this 'better system' look like? How is the subversion project, Tigris, doing at creating a new version control system? Basically, does the Open Source Community need new tools in this aspect of development? And if so, how should these new tools look?"
Clearcase is where its at. I admit its nowhere near free, but I don't see anything coming close to rivaling it from either the commercial or free/open source space. As well, it ties into some of the other Rational Products pretty well, especially with UCM and Clearquest for bug tracking.
I've used CVS and Visual Source Safe (ick) before. But at my current job we use Perforce (a commercial product) and it rocks. There's clients for just about every known platform, a slick graphical GUI for windows (and they're working on a linux one), and there's this local webserver gui that works for all the platforms if you need something graphical to look at. The interfact to it rocks, the merging and branching rocks, and it is super flexible. We have some scripts set up so we can close bugs in our bugzilla database from some special tags in the description of a changelist (a changelist is what gets submitted when you check stuff back in).
add that to cvs and make it actually work correctly and it would be pretty good.
at least that's what I miss the most when using cvs - the ability to change several files and commit them at once and when I do an update on a file it sould figure out all the dependencies on all other files ant update those as well. how sould it figure this out? simple - all the files that were commited at one time sould be also updated together, because it is bloody likely that they depend on each other.
of course this process should be repeated on all files that are a part of the patchset so that after updating a single file to a new version all the other files are compatible with it.
and yes, I know this could be theoretically done with tagging but then I would have to tag all files when commiting every time and it still does not handle the case when one file of the patchset depends on some other patchset.
I am SO cool I can keep meat fresh for a WEEK!!!!
Absolutely key is (relatively) easy integration with IDEs. Preferably a nice set of APIs for any IDE creators to use to interact with the version control server. I would imagine those same APIs could then be used by any GUI developers of the version control system. IMO without the ability of the system to integrate well with IDEs adoption would be slow.
Developers: We can use your help.
Probably to make the 'next leap', so to speak, in version control systems for programming is to design or modify a language so it is more version control friendly, or add much more language-sensitivity to the version control system.
Most people will probably hate this, but for instance, if a comment for a specific line/block of code always had to appear in a specific area or syntactically consistant way such that the version control system can recognize that if a piece of code changed, but not the comments for that code, it could ask if the comments for the code need to be updated as well. Or if a function's parameters or return value have changed, whether or not all instances/uses of that function have also been changed, etc.
That is not to say that you cannot create a great system on top of existing languages, but that perhaps making some minor tweaks in the language to make the language itself easier to manage/version, then this may open up new tool possibilities.
IMHO, these are the bare minumum requirements:
:-)
1. atomic commits - your change happens only if all the
files can be processed. This prevents a corrupted workspace
when CVS processes half your files in a commit and then exits
on an error throwing the other half of your files on the floor.
2. change list management - all commits have a unique
reference number. CVS process files by directory instead of
by workspace, so it is impossible to tell which files are
associated with a commit.
3. access control by workspace or workspace directory - the
ability to give certain users or groups access to certain
workspaces or directories. Ideally, access control can be by
done by bug id.
4. graphical resolve of conflicts - a graphical three-way
diff is the only way to resolve complex conflicts
5. The ability to move files and directories and maintain
file history and label integrity from the client. CVS
requires the whole workspace to be locked so that moves can
be performed on the server side and does not maintain label
integrity.
6. web viewer and graphical difference viewer - the ability
to browse via the web change set lists to see what files
changed and what the actual differences were.
7. the ability to integrate workspaces across projects - the
ability to arbitrarily merge/integrate any source code from
any project to any other project.
8. powerful labeling features (parallel development and
prior version support).
9. rollback or undo multiple changes - this is great way to
recover from a developer commit disaster.
10. multi platform support - must run on all platforms.
11. command line and graphical interface. Command line for
scripts and graphical interface for those who can't work
without it.
12. push and pull notifications - built in support for e-mail
and news group notification of changes in the workspace.
Your humble build servant
Now, going against all political correctness, what about the versioning system coming with .Net? It's clean, powerful, easy to use and was built from the ground up for collaborative development. Yeah it may be from M$, but it's still a powerful option. Why shoot yourself in the foot just on the basis of "we don't like them"? Even if the product is better?
1. Documentation is piss-poor. There's an easy solution to that one, but nobody likes writing documentation.
.CVS instead?
./src/ -name "*.java" | xargs -n 100 | cvs add' just to hunt bring in my new source code.
2. Updates don't always work as expected. They won't grab new directories and a few other quirky things.
3. Empty directories should be pruned by default in a checkout or update.
4. I'm tired of seeing a CVS directory everywhere I look. How about
5. Access control is poorly handled. It's good that you can map virtual user names, but it would also be useful to control access by groups.
6. Local CVS tree file ownership is by user, not the CVS owner. This opens up all manner of problems for users with a local CVS repository. Repository data should be in a non-user account, checkout should force authentication, and the server should handle who has access to what. This would not be tremendously hard to manage, since in the general case a user has access to a project or not. Fine-grained access control of the repository isn't a common necessity.
7. Plays badly with (most) IDEs. When I want to work on a project in an IDE, it floods my checked out directories with all manner of crap I don't want in the repository. You can set up refuse files to clean these out, but it might break your IDE project. This is more a fault of IDEs than CVS, really.
8. Needs smarter add functionality. I don't like writing stuff like 'find
9. CVS is a boring acronym.
10. I can't think of a tenth thing.
Bush Lies Watch
Basically, does the Open Source Community need new tools in this aspect of development?
Why only ask about the open source community. Do programmers need new configuration management tools?
CVS works fine for me. BitKeeper seems nice too. What I hate is that there's so much controversy just because BitKeeper isn't open source.
This type of thing may be out there already, but it would be great to have system to link the CVS like control with bug submission, so checking out files will also give you the set of submitted bugs related to those files.
Of course a strict bug submission policy would be required to make this possible, but surely something like this could be done?
An added benefit would be clearer bug submissions which would help development to no end...
"The large print giveth, and the small print taketh away" -Tom Waits
I use Vesta at work and find that is is better than CVS. One of the major differences is that it is also a build environment. That means that you along with your code, you can have the compiler versions that you used to build the code with. Vesta does the building within itself and then "ships" the executable to where you need it.
It is also easy to work concurrently.
I believe that you can also do the following: User X checks out and edits file A.
User Y checks out and edits file B.
User X calls user Y to test file A's changes with file B's changes.
User Y tells vesta to build with the checked out version (X's checkout) of file A.
User Y builds and tests the two edits together.
One other important feature for large projects is that Vesta intelligently caches created files. So, if User X and Y are working on the same project, then they can save on compile time by only creating files once and sharing them if possible. This is a necessary feature in large projects.
Anyhow, check out the webpage at http://vesta.sourceforge.net.
Don't pet the burning dog
- The file you want versioned.
- The archive that holds it.
- The workfile you extracted from an archive.
- The shadow file automatically extracted from an archive.
- A directory.
- A project, which is not always 1:1 with a directory.
- A view, which is not a subset of files or directories.
For instance, I may have the file archive.c,v which I check out as myfile.c, which is shadowed as mainfile.c, which exists in multiple projects, inside different subdirectories, exposed whenever I have a view of a particular time on a particular branch for a given subset of a module.Everytime a version control system tries to combine things you run into problems. Take the GUI version of PVCS, which called Projects a collection of files (from different directories) -- which ended up enforcing that all filenames had to be unique, even if in different directories. And what they call Views is actually a subset of the list of available filenames.
Ever get the idea developers are so into archiving versions of a file that they gloss over the fact the file organization itself is a structure that also needs preserving?
Sure. Are you sitting comfortably? Then I shall begin:
Now kindly shut up.
Maybe it's time for a major shift in cod storage.
Let's get rid of the file system/directory stucture schema and go with a completely revamped code storage method.
This has a ton of implications, but one thing that everyone seems to ask for that is difficult to solve on the old model is easy to work with if you remove the files and directories - sub-file VC. Being able to move modules from file to file, split files, move directories, etc.
The files and directories are there to help us understand the structure of the project, they were not meant to dictate the structure to us. We've locked ourselves into them so much so that we can't restructure the project without losing a lot of the benefits of VC.
Let's stuff our code into a database (which is like a more powerful file system, if you can't get your head around the idea). Atom updates can be built in. Symlinks are simple. Shifting a piece fo code to another 'file' is simple and the VC is not lost.
I can't be the first person to have thought of this - why hasn't it been done? Possible cons are:
Until the compilers and IDEs understand the new schema (regarding header files, includes, etc) the VC will also have to provide scripts to combine portions of code into files that the compilers can use.
How do we store the data in the database - it would depend largely on the language. Would we put a function in a blob of a record, or maybe even do line by line records. In highly OO languages (java) we could structure the database so there are class records that link to member records that link to variable and function records, etc.
Eventually the toolchains will attach to the DB directly.
Consider how this would aid huge and tiny projects alike.
I swear, the sooner we get rid of the file system (as is) the better - not just for this, but for all our information. But let's not get ahead of ourselves.
-Adam
That's part of what we're doing in Stellation. Our basic
view is that source files combine storage and organization
in unfortunate ways. So we want to break that linkage: code
lives in the database, stored as small pieces. Pseudo-files
are generated to give you organizational views of the system.
Because storage and organization are distinct, there's
no reason that a given chunk of code can't be viewed in multiple
pseudo-files.
The big catch is that there
are an awful lot of very useful tools out there, and they're
not going to give up their filesystems overnight. So you need
to be able to both discard the file notion when it's appropriate,
but at the same time to preserve the ability to use a filesystem
when necessary. Stellation pseudo files can always be exported
into a real filesystem to work with tools that don't understand
it's database storage model.
-Mark
I have been using the Eclipse Open Source IDE for a while and it integrates very well with CVS. It actually even adds some of the features many posts are looking for. And for you Java nerds (like me) check out the Easy Struts Plugin it will save you hours writing those action, form beans, etc. Happy coding.
Microsoft (who makes Visual SourceSafe) uses their own version control system (not VSS). I wish they would make that available instead of VSS.