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?"
Obviously these new tools should have little functionality masked by really fancy GUI. At least, that's what I've been trained to like.
Shurely, the Tigris project subversion (http://subversion.tigris.org/)??
"Elmo knows where you live!" - The Simpsons
"My question is exactly what would this 'better system' look like?"
You said it, BitKeeper. It's there, it's very good, don't people have anything better to do than nagging about other people just charging for their own work?
If you want to give away your work, please do (I'm happy to use it) but you are not BitMovers (the company) mom and have no business telling them what to do.
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).
Shouldn't we just use whatever source control system the CVS developers use?
I am a Karma Library.
Subversion isn't the only open-source revision control system out there. Check out these projects as well:
OpenCM
arch
Stellation
PRCS
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
CVS may be the best open source version control tool right now, it still suffers from a lot of shortcomings.
.. doesn't handle big binary files in a satisfactory way
.. but I'm really waiting for subversion to get mature and usable for production..
Generally speaking, stuff like commit emails need the addition of specific wrappers (see http://cvsreport.sourceforge.net for instance), and CVS doesn't scale well to big projects
It's quite usable
Regardless of where your particular alliegances lie---whether it be with arch or subversion or opencms or bitkeeper or whatever---it does seem obvious that the open source community is asking things of CVS that it is just not able to deliver. One need only look at some of the problems large projects like GCC have with it to realize that some alternative is needed.
And if that doesn't convince you, well, it's not for nothing that some of the primary developers of CVS are now working on subversion.
Now, of the new crop of tools, the only one I've played with extensively is subversion---but I am absolutely blown away by how well it seems to make common operations simple. Even with its documentation in a very rough state, and despite its many architectural differences from CVS (with which I have several years of experience), I was able to figure out how to maintain a vendor branch and local modifications, perform updates on both, merge them, tag releases, etc., very quickly and easily. Its developers have obviously looked at CVS to see what things it does not do well that people do frequently, and designed accordingly.
Is subversion for you? Who knows. But if you use CVS a lot---especially if you find yourself cursing CVS a lot---you should do yourself a favor and look at some of the alternatives. A lot of lessons have been learned, and you should avail yourself of the benefits.
Urgle.
In fact, you exhibit a common misconception. If you want version control, CVS do the work. But what you seem looking for, and what do many of the alternative proposed in the replies is configuration management.
Now, what an ideal system would be? I don't think one size fit all. You need very quick local net access (bye bye CC), and you need infrequently, losely connected internet developpers. But not at the same time. So I don't think tere is one unique response to your question.
Clearcase might cut it for most corporate types. Sure it's got tons of features, but you'll get a groetesque design and a bad implementation for free.
(Try scaling a clearcase server and you'll see how bad the design is... Hint: Adding more CPUs won't help you.) No, most people won't care, but you do if you need to scale it to several thousands of active developers.
Even though I dislike the product, its has more functions than you'll ever need. Integration with different platforms and products are superb, if you're willing to pay...
However it lacks in areas where the developer isn't fully connected (i.e. with LAN access to the view and vob servers).
IMNHO, what the open source community, by definition, needs is something that'll work in a distributed (and disconnected) environment. Clearcase does NOT come even close to delivering that, CVS does, but functionality wise, BitKeeper blows them both away.
I haven't looked at SubVersion in a long time (before it was self hosting) and it looked promising, but IIRC it lacked some of the more advanced functionality that BitKeeper has.
Personally I'd much prefere using a completely free version. Not because I don't like to support the BitKeeper team (I'll buy the product if I use it commercially!), but because of the open logging function.
It just comes down to the fact that I like my privacy...
-oswa
My largest problem with most of these revision control systems for Open source is the Lack of the Windows based Servers...I Know I know...but unfortunately most of the development I do is for the company I work for, and I just don't have a choice in these things. I have to develop for windows here, and I have to use windows systems, NO Linux, BSD, etc allowed. However I can't stand most of the Closed Source systems, I would love to be able to use one of the open source systems at work. Before you get tofar down that road of thought, Cygnus(or VMware, etc) is not the right fix here either, the server team does not allow that sort of software on the servers.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Look at Continuus Versioning Control System: every change on an object belongs to a certain so-called "task" (or more than one task). tasks belong to a certain task-folder and task-folders can used for releases. Continuus has a nice flexible database, but the disadvantage of this is that it makes it complicated for people to learn it fast.
- fake out CVS by doing a remove/add pair on every file you want to move (which means you lose the revision history of each such file!), or
- manually move files around in the repository (which entirely defeats the purpose of using a revision control system in the first place!)
If anyone out there creates a successor to CVS, please fix this fatal flaw!ClearCASE rocks in terms of scriptability, built-in triggers, etc. Also I much prefer branching individual files and using views, to the typical Open Source CM scheme of having separate trees. Too bad that the ClearCASE *nix GUI has gotten progressively worse for two major releases since their high-water mark (IMHO), ClearCASE 2.1. They've never fixed the problem where sometimes you click to select a version and it looks selected but isn't really, and in many cases have introduced GUI bugs, made the whole thing slower by using a special "properties browser", etc. I have a bunch of hacks in ~/.grp to get it customized back to the way that it used to work so that it's even halfway usable.
Your right to not believe: Americans United for Separation of Church and
I'm a ClearCase specialist so I'm biased.
However ClearCase has some -very- good features, and here is what I would arrive at (ideally):
1) Make your repository a mountable file system, supporting multiple types of connection, NFS, SMB, Active Directory, FTP, etc.. When connecting you must specify a profile to be used.
2) Make every user have a number of profiles (Min:1) (like ClearCase views), these profiles contain -all- the info needed to access file versions correctly. They should allow sharing ('base my profile X on the profile Y created by user Z'). And support concepts such as labelling, conditional branching, etc..
3) All profiles are managed from a central server (redundancy?) via a web interface (to achive cross-platform conformity) and command-line interface (SSH based) for scripting/power-users.
I could go on forever, but I think the three above points are the things that matter most to me. Obviously you also need security, administration, storage, etc.. but I think that making files available simultaneously via many common file sharing protocols would produce the greatest benefit.
Finally: MAKE DIRECTORIES VERSIONABLE/BRANCHABLE!, yes it causes some potential headaches, but it's benefits easily outweigh them.
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
I think in designing a source control system you have to be aware that there are two different usage models.
CVS has been designed and mostly used for the latter. Tools like SourceSafe and Clearcase were designed, and are almost exclusively used for the former.
One of the obvious differences in approach is file locking on checkout. Obviously there are others as well.
I don't see any reason why one tool could address both models, with suitable ruleset configuration for the administrator. But you have to recognise, and design for, one or the other or both models from the start.
Never trust a man in a blue trench coat, Never drive a car when you're dead
Trying to maintain a huge source database with hundreds of developers is basically impossible if there isn't a well established team structure with source managers. When there are fewer than 6 developers working on the same project, it is fairly smoothe. With 12 or more developers, it gets exponentially harder to figure what's going on. Unless there are very few check-ins or changes and the source is in maintenance mode.
In active development phase, there may be dozens to hundreds of checkin's and changes per day, which may cause an unknown number of effects. It doesn't matter which development style you use, because in the end it comes down to whether or not the product is divided into small manageable chunks. Distributed development is a management artform and very few managers know how to do it effectively. I would put forth the idea that the tool for source management is really only 20% of the equation of distributed development/source management. Trying to address the problem by focusing on the symptons isn't a solution to the real cause of the illness.
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.
A decent version control system should provide support for change packages - (atomic groups of changes that must be promoted through the system as an single unit). It also needs to provide support to manage a set of stages in the developement cycle so that changes can travel through development, qa, and production in an easily manageable manner. Hooks to integrate with issue tracking systems is also importand. Perforce has most of these features but they are somewhat cumbersome to use. MKS Source Integrity probably also has these features.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
I am working at a really large corporation and we are using clearcase. All I can tell CC is really sucks. CC always needs some maintenance. We have a dedicated CC expert and IT for maintaining CC. And CC is painfully slow if you compile something from the repository (at least on Solaris). So, we use the snapshot-view feature which is more like CVS. In short, we use CC as it were CVS.
Of course, corporate policy forbids us to use CVS.
Government cannot make man richer, but it can make him poorer. - Ludwig von Mises
Bush Lies Watch
CVS does handle locks. It is based off of RCS, which uses locks. The option wasn't removed, just made hard to find. Look at the admin command. Locks are requrired when you have concerent development on binary files, which can't be merged.
Useing locks on text files is normally counter-productive.
C 113
...
http://www.cvshome.org/docs/manual/cvs_16.html#SE
-l[rev]
Lock the revision with number rev. If a branch is given, lock the latest revision on that branch. If rev is omitted, lock the latest revision on the default branch. There can be no space between `-l' and its argument.
-L
Set locking to strict. Strict locking means that the owner of an RCS file is not exempt from locking for checkin. For use with CVS, strict locking must be set; see the discussion under the `-l' option above.
(appended to the end of comments you post, 120 chars)
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.
I tested it by putting the code under version control, but then I discovered a bug...
I've never seen my code since...
... that the problem needs to be reimagined.
I haven't looked at all of the new revision control systems, but they all seem to be evolutionary modifications rather than revolutionary changes to how things are done.
I don't think we'll see a truly successful next-generation revision control system until somebody tackles the problem from the ground up in an imaginative way.
CVS is great, but it doesn't know enough about common file types that are checked in to it. It doesn't do diffs between image files that it considers "binary" format. Also PDFs, Word Documents, and the like could have better than "binary" file support. I am constantly annoyed that I can't change tabs to spaces or adjust indentation in source files without causing diffs. Both of those problems would be solved if CVS knew more about the file type. The second can theoretically be solved by CVS by adding checkin and checkout scripts for each file. The script would remove all whitespace from the beginning of each line on commit and then pretty print the output on checkout. However, I haven't found scripts that will do so yet.
Could not disagree more. At my previous job, it took a team of 5 CC guys to support a team of 50 coders. It never worked right. The *nix support was OK but the NT support was a nightmare. The view concept of CC is great in theory, but in practise, it's a disaster: hours before the final build, everybody is scrambling to verify that indeed the build team is pulling the right files from the right view, etc.
Like in in many other areas of sw development, simplicity is often the best choice you can ever make. CVS is simple. It works. It's easy to audit, it's really cross platform and with so many OSS projects using it, it's worth learning the 5 or 6 commands you'll ever need. The thing that the cvs documentation explains really well is that the key to successful CM lies no in the tool but in the processes and the communication between team members.
there's no place like ~
Consultants usually argue that new doesn't work (a solid trend in hisotry), but we try it any way because of hope this time it may be different. And it usually isn't.
By Linus making this decision, he's effectively forcing a user base, and there by excercising the SCM tool fairly heavily.
Lots of usage, combined with small, incremental revision, is the best way to get controlled quality. Since the product is "new," people are going to be more likely to stand up and rattle a little louder when request a fix.
At the 50,000ft view, this may be the way Linus gets a SCM system of decent quality that operates the way he thinks it should. Frankly, I can't say that's a bad thing.
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
Look, CVS is king.
Yes, King.
I would not hesitate to say that it has it's share of difficulties, but there is no way anything is going to replace it anytime soon. There are many meta-features of CVS that make it unable to be replaced:
1. Multi-platform: I don't mean 3 or 4 or even 5 or 6, bla bla bla. I mean EVERYWHERE. I've seen CVS on more places that anything besides emacs and gcc. And really, anyplace gcc or emacs goes, cvs is the third guy there.
2. Massive Acceptance: CVS is everywhere. 10 million people use it with sourceforge. Another few million elsewhere. It is the common thread that binds us together (kinda like the force!)
3. Massive, Massive Tool support: This is my favorite. You can use it about a hundred different ways. Not 1 gui, but 50!. It goes into command line apps like great!. Show me another tool that has integration with the windows explorer (via TortoiseCVS) like it has. You Can't. (Don't even try that god-awful Bitkeeper's integration:yuk!)
4. SimplicityIt's REALLY simple to use. It's not that complicated. If CVS throws you for a loop, maybe software devleopment really isn't where you should be working. The incompetence among developers is what makes all software look bad.
5. Protocols: You can run CVS thru SSH, RSH, PServer, File Access, and more... It fits into every environment. It works across any damn network. It can jump tall buildings in a single bound!
Really, until someone makes something that trounces CVS in all those areas, AND provides features that "I can't live without" CVS will Rule.
"...In your answer, ignore facts. Just go with what feels true..."
- 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?
Might as well burn some karma and give my experience with various systems:
RCS: primitive, but ok
CVS: hated it. hate, hate, hate automatic merges; don't trust 'em. And WinCVS...man, my Milton's Ant Farm had fewer bugs.
VSS: not bad, actually. I love file locking, it seems pretty easy to tag various milestone releases, a reasonably clean interface, and easy access to pretty much everything I want to do. Some quirks but nothing major, very usable.
ClearCase: jury's still out but so far I don't like. Very complex and proccess heavy; it's out to be the manager's buddy, not the engineer's. Everything has to be done in the context of a distict "activity" (plus we've had some trouble settling on rules for if a checkin automatically closes the said activity...) and concepts like "VOBs" and "Integration streams" and "development streams" are hard to keep your head around. And it's slow and generally process heavy.
EveryOnceInAWhileCopyEverythingToABackupDir: this is the one I usuaslly end up with when I'm on my own.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
In the middle of the CVS bashing, remember that lack of source code version control is listed as a classical mistake in most software engineering literature - at least in what I've read.
When things cool down (yeah, right), I'll look at the other projects. Until then, I'll live reasonably happily with CVS.
Stop the brainwash
(Try scaling a clearcase server and you'll see how bad the design is... Hint: Adding more CPUs won't help you.) Try adding more memory and distributing yor server duties over a cluster and that will help.
Blaze a trail to the New World
I agree. I'm mostly thinking along the lines of MS Visual Studio's integration with Visual SourceSafe. Yes, like everyone else I hate VSS. But the VB6 IDE makes checking in and out as easy as it could be by right clicking on the module name in the project "explorer" window. With a good set of APIs maybe I could easily add the same feature to some Linux IDEs for integration with a new version control system, which I'd much rather work on than VB.
Developers: We can use your help.
That's because they have a personal invested interest in what gets produced, and that's a strong motivation for fixing problems.
One should only be allowed to pollute upsteam.
Verizon control? That's a great idea! We should enforce regulations as to how many annoying commercials they are allowed to air in one day!
Can you hear me now? Good...
dmarien
Every time the issue of version control and source code management comes up here, I've never seen anyone mention Aegis, which appears to have been designed to address the missing functionality in tools such as CVS which focus solely or mostly on simply maintaining multiple versions of a source base concurrently. Here's an excerpt from the CVS comparison in the CVS Transition Guide:
1.5.1. Why should I change from CVS to Aegis?
The software seems to be pretty mature (currently at version 4.5, first released in 1991). Has anyone here used it?
In Soviet Russia, Jesus asks: "What Would You Do?"
Clearcase scales well across multiple projects (well, DUHH!), but not well within a project.
Been there, done that.
You could've hired me.
Clearcase certinly benefits from having a build manager on hand who knows Clearcase. Personally, I always thought the team lead should have this skill. The learning curve is steep though, and it is easy to fsck yourself up badly if you don't know what you are doing. The best advice in that case is "stop, read, learn, try to undo what you did. Rinse, lather, Rrepeat."
You could've hired me.
I've never used subversion, so I may be wrong. However, a brief scan of their web site makes no mention of change sets. If that means it's file based (like rcs, CVS and SCCS), then it stands no chance. Change sets are an essential feature of any modern source control system. I wasn't convinced until I'd played around with TrueChange. Since then, I wouldn't consider going back. BitKeeper is designed from the ground up to support changesets, and it's not something that can be easily tagged on at a later date. For that reason alone, subversion won't succeed. PRCS looks promising, though...
"The invisible and the non-existent look very much alike." -- Delos B. McKown
You roll your own when you really want for fork something off the main branch and need to preferentially select your changes over mainstream development.
You get into trouble when you have inexperienced Clearcase admins not knowing what they're doing (and this is understandable, given the learning curve steepness), or worse, developers left to their own devices.
Clearcase really is a tool for a team lead to use to manage the various forks of their project.
You could've hired me.
- Scratch pad versions. Ever needed to play around
with a piece of code (put in debug statements,
or change part of it temporarily to help debug
something) but didn't want to check it out
and have the threat of making the changes
accidentally permanent? Envy had the ability
to make a "scratch" version of a file - letting
you edit it, but not worry about accidental
check ins, or forgetting that you had made a
file writeable.
- Version/Releases. Not only could you label
a specific state of an application a "version"
but you could also label a version of an
app a "release". This allowed some subtle
distinctions between "ok here's a workable
version we can get back to (demo)" and "here's
the real, outgoing released version".
- Manager. Code could be given specific people
that were the manager, or "owner" of a piece
of code. If you wanted to enter your changes
into the code base in general, you had to get
the owner to do it. This control could be
anywhere from every check-in, to version or
releases. An owner could give permissions to
other people as well.
- Multiple checkouts. Envy recognized that
sometimes people have to work on the same
file, as much as its best prevented. So,
it allowed multiple check-outs, with facilities
to integrated the files back together on
check-in.
It was quite complex, but looking back at it I now understand why many of the facilities were there and die to have them for my team. We're using SourceSafe (blech), and it works ok, but something like Envy would be great.The product demo was impressive. Seems to a complete SCM tool. The problem with most source code tools like SourceForge and CVS is that they don't really address the entire SCM process in one integrated tool. Why is that? What tools to you use for Requirements tracking? Defect tracking? Testing?
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
At some point you need to develop instead of monkey around with the source code control tool.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
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
Aegis enforces a development process which requires that change sets ``work'' before they may be integrated into the project baseline. Works includes requiring that change sets build successfully, and (optionally) that they include and pass tests. It also ensures that code reviews have been performed.
--- Fox
In fact, the only thing I see as a major issue with svn (other than their fscking slow-ass site) is the fact that it is pre-alpha code. I want to use it now, dammit. In fact, I'm just starting two new personal projects; I think I'll give it a shot. Worst case, if they do change the filesystem, I'll write a damn conversion program myself.
Many of us are in the same boat: GB repositories with untold value (in the revision history).
That means one thing: use CVS, something CVS compatible or something that can read and understand a CVS repository. (Here I explain why Perforce didn't work for me.)
In fact, most of the commercial SCM tools do exactly that. ClearCase
and Perforce both use databases for storage at the back end. So
does Stellation.
-Mark
dosomthing.c has amoung it's functions
formatString
formatDate
formatBill
dosomthingelse.c has amoung it's functions
formatString (copy pasted from dosomthing.c with a few fixes)
formatTime
formatAddress
I wan't to move all the format functions into
formatData.c
merging formatString
and preserving the change history on the rest.
thank God the internet isn't a human right.
I just want a tool that, when someone checks something in/commits, warns them when they are undoing the changes of the previous revision. How hard would it be to have something automatically diff the last 3 revisions and throw up a warning?
XML could be tracked using DTD changes.
Java could use the C++ methods.
Change control would be so much easier!
The other option is just to look at all the changes in the commit, and try to match up things that have moved or been coppied, in the file or accross multiple files, that shouldn't be too hard, using per line hashing and match rejection to reduce the workload.
thank God the internet isn't a human right.
... until I tried one.
My IDE can
-- rename a variable or class, and have the changes propagate through every file in the project
-- Flag most syntax errors or mismatched parameters I produce while I write them
-- press a key and have every use of the variable the cursor is on highlighted in purple. The uses outside the window is shown in purple on the scroll bar.
And dozens of other things. Sure, you can do them all by hand, but much slower and more error prone.
CVS is the tool I've used most often to crack the Windows monopoly at client companies. CVS is so ubiquitous and has so many advantages over VSS that it's not difficult to convince people to try it out. In some cases, I've even managed to get companies to set up a Linux box to do it.
I've never come across a single case of anyone who switched saying "I prefer VSS" or even "I miss such-and-such feature from VSS".
VSS is a hangover from the bad old days of PC computing, when everything was file-based and local-network oriented and the Internet was a mysterious thing best ignored. It doesn't seem to have managed to shake that legacy in the slightest.
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
My question is exactly what would this 'better system' look like?
Well, first a volunteer graphic designer needs to be found. The program needs to be themable. This should be right at the top of the requirements document. It should offer a remote api (CORBA?) so that other programs can send it messages to change the appearance of the buttons, scroll bars, etc. There should be a web interface so that you can use another computer in case you cannot use your own monitor because the default color scheme is unacceptable for professional work.
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
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.
See:
http://www.perforce.com/perforce/branch.html
Which explains the merge process in Perforce.
-Stu
As for CVS, I never suggested it scales better, though, in some cases, it's lower overhead might make it seam that way. In fact, I liked working with Clearcase, but it didn't strike me as a tool that was good for projects with large numbers (say, hundreds, or thousands) of contributors, on large projects, unless you segmented the project (which you should do anyway).
The combination of project segmentation and Multisite might be a winning combination, though.
The biggest "problems" with Clearcase are the steep learning curve (though I have found learning CVS after Clearcase a pain because of what it lacks (directories as objects, views, etc.) and labeling overhead.
You could've hired me.
4) Keeps track of branches and merges between branches. With CVS, you have to remember to mark the points where you merged.
Overall, though, I find CVS a lot more pleasant to use, and it does a much better job of merging.
SourceSafe and SubVersion create branches as separate paths within the repository, whereas CVS creates branches in revision histories under the same path.
Pretty much all new code. New data structures. Slightly different view of the problem. Totally different network protocalls. And probbably zero interoperability.
Sounds like a good time to change the name. Even if many of the devlopers are the same.
(I'm not a developer, just an observer of the project.)
Subversion is nearing a first final release. The alpha version is just around the corner, and development is very active.
Subversion is basically CVS done right. Natively client/server, atomic commits, proper handling of binary files, proper versioning of everything - including directories and file metadata, and much more. Go read about it at http://subversion.tigris.org
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
Clearcase can do all that, to be sure, but the emphasis is on reserved checkouts, so the "lots of readers, few committers" sourceforge-style model can't be applied without some tweaking. The whole notion of a read-only VOB bucks the way Clearcase is intended to be used.
You could've hired me.
ccache.samba.org
find + sed
Oh please!
So if you want to change variable x to y, you will also change all exists to eyists, right? What you really have to do is to manually check each and every one of those occurences to try to decide if needs to be changed or not.
Syntax checking is what good eyes and good compilers are for.
Sure you can spend your brainpower on hunting syntax errors, but why not use it for more productive things when the IDE can do it for you? And of course the compiler will always catch syntax errors, but instead of finding them when you type them there is a much longer turnaround time.
I have no idea what "raw complexity of a GUI-based system" is supposed to be. Visual C++ may be crap, I know nothing about that. I'm talking about IDEA for Java. All it's auto checking does is to mark errors in red. It's up to you to if and when you want to do anything about them.
Yes!
That way one can search, sort, filter, cross-reference, report, etc. any way they want, not just those anticipated by the original designers.
Databases can also be communicated with by multiple languages.
Table-ized A.I.
The listed address had an extra space and HTML isn't too tough ;o)
1 /CVS.html
http://linux.oreillynet.com/pub/a/linux/2002/01/3
That is a psychological problem, not an
actual tool problem.
You can bet I'll try cvs2svn when it's ready! I am very much looking forward to subversion. It looks so nice on paper. I really am hoping it succeeds.
Weird. Maybe you ought to get a name?
I can only assume you're talking about some other Vesta from the one I'm familiar with, because:
CVS is teh suck. Use Vesta instead.
However, the last time I looked at subversion, it had some security shortcomings too. One which looked simple to overcome was that, since it used ftp, it sent passwords in the clear over the Internet to change data. This is a crazy thing to do, but is easily fixed (e.g., by using sftp instead of ftp).
More serious is the notion in subversion that all developers are totally trustworthy. It appears that any developer could modify the files on the code server and make it appear that someone ELSE made a given change. Now clearly developers with passwords have to be trusted to some extent, and certainly SOMEBODY has to be trustworthy (e.g., the server administrator or the person who validates keys), but this kind of total trust of ALL developers isn't warranted in many cases. Even if you expect others to find a security flaw, you'd like some mechanism to backtrack to who made the changes. I didn't do a serious security analysis to see if subdomain countered this, though, and I haven't followed it since. I'd be curious if others have examined the issue more closely.
- David A. Wheeler (see my Secure Programming HOWTO)
Source control should be somebody's job, if only to ensure that you can rebuild the binaries you make and have backups as necesary. Version control is a logical extention of this.
Whenever something is somebody's job, they're gonna set down rules. Sometimes these rules need to be locally broken in a way that doesn't affect others. This need not be trivial, but it should be possible. It seams reasonable that if an individual developer needs a custom fork to try something for a few days, they should learn a bit of the source control system so they know how to do it. This does not mean that all developers need to be experts in that system.
You could've hired me.
mcvs mv foo.c bar.c
As for migration, Meta-CVS can import snapshots and figure out file moves. So it can ``reverse engineer'' those simulated renames you did in your CVS project by removing and adding. You just need to feed it a sequence of snapshots.
Unfortunately, Meta-CVS runs only under Linux; but that will change with increasing popularity.
(* there is another way to do this that is more portable. It is to use a very feature-rich data store known as a file system. *)
I *hate* existing file systems. The world is not a fricken tree, but a complex graph, so why should I be forced to force everything into a g*d d*mned tree?
They were fine for CPM-sized systmes, but suck in the real info age and will only suck more and more until they are replaced by relational databases or at least set-based systems.
Now where did I put that $@#!% relaxation medication?
Table-ized A.I.
I took a short look at the arch home page. Support for sftp still isn't built-in (so it's still dreadfully insecure), but there is a separate patch available to support sftp. I suspect that eventually arch will support sftp and/or other things to replace the absurd "password in the clear" approach it's currently using.
However, it still isn't clear to me that a developer can't modify other files in supposedly "frozen" copies in arch. arch takes a very unusual approach to repositories - which is interesting! - but it appears that Joe Programmer might be able to modify other files than the one Joe is supposed to be modifying. Or perhaps Joe changes "older" versions that he's submitted, screwing up configuration management. Perhaps arch counters this, but I haven't seen any analysis of it that way (please let me know if there are any!!). The fact that arch still requires passwords in the clear doesn't exactly give me warm fuzzies about its security; writing secure programs isn't trivial and requires a commitment to do so.
Arch is actually quite interesting in many ways... but the security issues do concern me.
- David A. Wheeler (see my Secure Programming HOWTO)
ObCVSWhinges:
On the whole CVS is good - in fact, in the most part it's good enough (ever heard the expression "The best is the enemy of the good"? Well, the good is the enemy of the best, too!).
My pains with it are
- It gradually gets slower as you add more files and revisions
- Inadequate hooks for plugging it into your bug tracker, work management system, database, toaster etc. The *info scripts exist but aren't really enough.
- There are obscure gotchas that mean I can't unreservedly reccomend it for use by just anybody (i.e. people without training/skills). These issues include problems with binary files being edited on several branches at once.
Oh yes, one last thing - use CSSC if you have to but don't use SCCS/CSSC if you can get yourself into a position where you don't have to. There are good reasons why the acronym "CSSC" expands to "Compatibly Stupid Source Control"!Actually, I *was* talking about "cleartool rmname" (which ClearCase allows you to abbreviate as "cleartool rm"). "cleartool rmelem" does not preserve an element's history at all; that's exactly its point.
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.