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?"
Fist Sport!
"Why did they cancel my favorite Sci-Fi show? I downloaded ALL the episodes!"
Obviously these new tools should have little functionality masked by really fancy GUI. At least, that's what I've been trained to like.
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.
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'm strongly leaning on the fact that Linus wants to 'dare to be different'. Whenever people do this because they want to push the envelope, it always comes back on them.
BitKeeper is an interesting idea, but in practice I haven't found it showstoppingly impressive. CVS is still one of the best revision control systems going, IMHO.
However, history has shown that when tools like BitKeeper hit the spotlight and it's their time to perform, the kinks are worked out after fast. It stands a chance of being a good tool for the job, if Linus and co. manage it properly.
// -- http://www.BRAD-X.com/ --
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).
There are many good tools that have been around for a long time. CVS is the obvious example. Maybe what should be considered is enhancing these tools to match some of the capabilities of their commercial counterparts. A list of capabilities can probably be summarized by the discussion that follows.
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
I've used Clearquest for over a year and I can tell you that it is a nightmare.
Completely unintuitive GUI and it is difficult to enter bugs into. Maybe they have fixed this in a later version but the email bug alerts don't have clickable links for developers to go straight to the bug in question.
Clearquest was designed by project managers FOR project managers. Any good developer would not go within a mile of it if they had the choice.
I agree, Clearcase is great - the only drawbacks that I can see are the steep learning curve and double steep price.
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.
There are plenty free and commercial version control systems out there. Unless you're a total egoist, there's no reason to write one from scratch. Instead, fork out some bucks and just get one.
From the CVS manual:
(the release command)
This command is meant to safely cancel the effect of `cvs checkout'. Since CVS doesn't lock files
Locking files is very important in a normal work enviroment, and CVS approach is more towards "loose" free project development.
I want tender love now!
Elkobim
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.
why are opensource projects so intent on reinventing the wheel everytime something isn't completely to their liking? isn't that a major part of the reason why things ARE OS? if you don't like it, change what you don't like, or add to it if you need to. like someone posted above, why not just extend CVS (or some already adopted control system)?
I think the practice of moderating posts to -1, troll is just not effective any more! Most people read at -1 anyway. Time for a new system?
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!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've used way too many different SCM systems in my career (CMS on a vax, PCMS on a vax, CVS, ClearWaste, sorry ClearCase, sccs, rcs), they all have good and bad points. From a developer's point of view, all the tools that management like are hated by the developers. People making these tools seem to forget that if the tool gets in the way of the developers job or is so awkward to use, he won't use it. CVS is the best of the bunch (IMO) at letting the developer do his main job of developing code.
My opinion, feel free to disagree; opinions are like a**holes, everybody has one.
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
I've tried to use CVS but ran into too many difficulties. with getting working versions of the site checked out into development web areas etc. Plus there wasn't a dummy way for windows users to check in/out files to their work areas on the server.
I've read all the info I can find about using version control for websites, but most of that doesn't go much past static html sites.
I'd gladly listen to any suggestions out there.
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 know it *wouldn't* be PVCS. I've been using it for a little while now at work, and it's aweful. The client's (X11, Windows, 'Web') are buggy as hell. If you're 'remote' you're forced to use an aweful web-interface (Java) that will drive you insane.
:-)
Yes, I have an opinion on this.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Bush Lies Watch
I dont know what the ideal interface should be, but know its NOTHING like CVS.
:just:for:for/your:project
Setting environment variables should not be _required_ to perform basic tasks, and the command line options shouldnt be more the 2 line of text !
Ideally the command line optiosn should be some remote resemblance to at least 1 other popular program, you should invent an entirely new command line export(syntax)
Backwards compatability is bad if it makes it hard for everyone for the rest of time.
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.
There are much better solutions than version control systems:
1) Don't have version control. Just have one single developer working on everything. Since humans are largely single-threaded, you have no locking to worry about.
2) Don't write software. If you're careful you can usually get away with mucking about on the web or playing nwn with the sound turned down in all but the smallest offices. You needn't worry about version control at all.
3) Seperate the development out properly so developers don't tread on each others feet. For example, get one programmer to always write the bottom 15% of each c++ program, and another to write the rest. The one only doing 15% of the c++ would then have enough spare time to do all the fortran77 bits.
That's all I can think of. I'm going home now, my head hurts.
I personally I have been looking for a versioning file system. That is hard drives are cheap and I would rather save every version of a file than lose one. Therefore my idea is to make network share that each read/write is logged. This is not a true version control system but more a backup system. However for one user it is good.
There is an improved (GPL)Version Control System it is just not released yet. *VS started as patches that were refused by CVS because the changes were to radical. It has grown from that code. I am not the developer of this black book project, but http://undeadlinux.com [EvilEntity Linux] will be one of the first beta tester outside of its current enviroment. *VS is used in full production, in a large programing shop. Since the project is not released I cannot speak the name as I don't want to steal their thunder, You'll know about it when it comes out!. So everyone can stay calm something better is comming down the pipe. From what I'm told, It will be out soon ???
Need help finding the flow? http://www.myspace.com/naturalismandbalance
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 ~
I really like CVS actually. I have few complaints - which is odd for me. In four years of constant use, I'd like to see things change primarily in the GUI's I use with it. I'd like...
1) FAST way of knowing what I've changed, globally. Using WinCVS is SLOW for this task.
2) No CVS folders in my local source. I don't know how you avoid this though. However when I move source from one machine to another, it breaks CVS. That is a Bad Thing.
3) A better/easier way of sending my revisions into an existing tree on a global basis. You can do this fairly easily in the CLI but it's invisible as to what you're doing. Something like a two-stage commit would be excellent for this, you ask it to do the merge and it responds with a list of the files and a few lines of diff before going on.
When you stop laughing, feel free to post a witty response!
Help! I'm stuck in a Wintel company and I can't get out.
[figz@figz figz]$ kill -9 `ps -ef | awk '$1=="figz" { print $2 }'`
> create a better system than CVS.
> subversion project
> how should these new tools look?"
Well, isn't it so, that usually a company publishes a great and useful product, having spent lots of money into research and development and then some other guys decide that, since everything should be free, they just rip off the idea and create a clone of that thing. Hail the glory invention of theft.
I might be wrong but I do not know a single *original* application, that was invented by a open source developer team and is widely used or was even copied by commercial companies.
Could someone tell me only ten applications, that fit the discription of being "Original" and "Open Source" and "innovative" and "free" as in free beer?
All widely used open source clones I know are just clones (heck - even Linux itself is just a clone).
Are there (only) ten original open source applications? I don't think so. This culture is based on other people's ideas, theft and (undoubtedly) sweat and skilled workers (but one might consider a experienced pickpocket a skilled worker, too...)
I give huge credits to all the great programmers and developers in open source, but innovation does obviously not come from this scene.
Open Source projects (kernel excepted of course) almost NEVER need complex version control systems. Studies have been done (and posted here I believe) that state that most projects are the work of 1-3 developers.
This is not the case for commercial development projects. However, these are larger, more complex projects.
This one also looks good:
http://www.opencm.org/
Here is a quick list of key features of OpenCM.
* For-real configurations! It's just amazing what CVS doesn't know.
* Ability to rename files without losing their history
* Access controls on lines of development (branches).
* Cryptographic authentication. This provides the ability to give developers accounts on the OpenCM repository without giving them an account on the underlying machine (OS), and makes multi-organization collaborations possible.
* End-to-end integrity controls. If a server has a bad file, or a replicating server actively attempts to replace the proper content, the end user can detect the error or substitution.
In future releases (coming soon), OpenCM will provide:
* Repository replication
* Disconnected commits (ever screwed up a code base on an airplane or a vacation and wished you could back out?
* Advisory access controls at the file level.
We have had these features working at various points (so we know they will work), but elected to remove them to make the 0.1 release available sooner.
http://vesta.sourceforge.net
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.
Would people like a CVS-like system that used for example a mySQL database? This would solve the locking and data integrity problems. It probably would also make it easier to extend.
I'm feeling curious if people would mind having the source code in a database, or they prefer text files like in CVS
At Microsoft they're using what seems to be a custom version of Perforce, and the rumours says it's the best system ever. Microsoft are being very hush-hush about it, as they think this system gives them a real competitive edge.
Remember that presentation on Windows development linked off Slashdot recently? The presentation showed how they had revamped their development and build system completely when doing Windows 2000. This was when they converted to their new system!
I with every fiber of being hate CVS. This is one area where most of the commercial products are vastly superior to open source. Starteam makes CVS it's whining little bitch. In case it wasn't abundently clear. I hate CVS.
This will be best revision control System after
some time
http://www.regexps.com/arch.html
I notice that they don't even use subversion themselves. Instead, they use a seemingly closed-source commercial product called SourceCast.
At work, we use CVS. While not everyone on the project uses it well, we end up using it effectively. We have had problems with people accidentally backing out changes because they didn't check their `cvs diff`, but other than that no other real problems.
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
The best thing I've ever used, hands down, is CMVC at IBM. It does 2 things which I think are critical: it integrates with the bug tracking system and it easily supports multiple releases concurrently (as in to check code in you need a "bug" that is accepted and that bug can be associated with multiple releases and can't be closed until you roll the fixes in to all the associated releases)
I've used CVS and Bugzilla for about 3 to 4 years now (bugzilla less, maybe 2.5 years) and CVS is great when you use it right and you do what it does. It seems like about half of the developers out there don't want to do that initially though. I think it starts to get very complex when you're supporting multiple releases (very common in a business, less so in opensource) also because you can make changes check code in and it will pretty much do it or it gives you some crazy error message that most people don't understand. Really CVS solves the file aspect of the problem and that's about it. It also has some implementation bugs, it needs a temporary space the size of the repository; suppose you build a release binary that's 100MB (not at all uncommon) and check it in because you release it and you've got 500MB of source code; after 3 or 4 releases you need a GB of space to do just about anything with the tree. Say you're shipping a CD image, you know with a JDK and a bunch of docs and stuff, release 3 betas and a release and you're possibly in the 2 to 3 GB range. Twice in business settings we've had to do major work on the CVS repository because our hardware was no longer large enough to support it. These are more extreme uses but they are common in a business that is trying to implement some good software engineering practices, much easier to get away in open source.
CVS isn't the most condusive to being used in a business setting where you want to have *Everything* in a tree. It simply starts to get slow and hard to use when the trees get big. Also the best way to use it is in the clearcase mode where everybody is doing everything on a branch and just the nomenclature of that sounds bad to most engineers in business, they don't like to branch and merge. Also, it has been my experience that until the team size get's to be in the 20s or so and the project is simply too big, every engineer should do a full build at least once a day, the whole branching parts of it methodoloy seems to encourage spot builds; no real reason it just seems that way from experience, doing a full checkout seems to take too long for some people or something. Also, simply doing updates isn't the best idea either because it seems like CVS becomes confused on some client platforms (**cough** windows) and after doing that for a week or so the sandbox isn't exactly like tip.
From what I've read, it sounds like subversion starts to fix the file level problems CVS has. That's huge. The next step is to couple the issue/bug tracking system to the actual file level version control system.
1. Changesets (aka patchsets) - remember a commit as a logical unit. "This changeset fixes ProblemReport #343242323".
2. Versioned directories - so you can track move/rename acurately and preserve the history of the contents of the file.
3. Work in a distributed environment: I don't mean: "let me checkout this directory from this server in Antarctica". I mean: "I have these three teams in my company, on three different continents , and I want to be able to syncronize them - without having a master that everybody depends upon. I want three separate (but related) repositories that can exchange changesets."
I apologize if the 3rd looks as it's only satisfied by BitKeeper. I haven't used BitKeeper but I used ClearCase and boy it sucks in a distributed environment: every three hours it syncs with remote servers and everything slows down...
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?
AccuRev.com ... supposed to be good stuff
Here at work, we use a nice program called Continuus/CM. It has all the fun features of CVS with a lot of extra features and a cool frontend. In the version control it has build in Task management and all the fun tools you need to manage a project, all you need is another enviroment (emacs?) to edit the files. I don't know any of the advanced features of the program, but if anyone else has any good experience with this program, please post away.
It's probebly not a program for Linux to move to since it is a little pricy from what I understand.
Its not what it is, its something else.
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
I'm really pissed that Chevrolet, General Motors, Honda, Toyota, Nissan, Acura, Audi, etc. are ripping off the Ford's idea.
Damn them for making better, cheaper, products with more features. What kind of innovation is that? It's all theft.
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.
Yes Subversion is a Tigris project, as the poster or at least the editor should have checked.
Thanks for the info. :)
I want tender love now!
Elkobim
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.
And so does Java, so does C++ with Doc++....
pardon my general .NET ignorance, but does the thing run on Linux? If it doesn't, then there's your answer for a lot of us here, I think...
"The best argument against democracy is a five minute chat with the average voter."
--Winston Churchill
One of the features that I really like about Clearcase is their integration into the filesystem. I can set a view and go crawling through a directory structure or set up symbolic links into said directory structure. If I use a different config spec, then I get a different outcome - completely transparent to any applications that are looking at the directory structure from within the view. Other CM tools want to take snapshots, extracting them into a filesystem.
Are there any less expensive alternatives to Clearcase that can do this? I've looked into Perforce, Bitkeeper, plus a few others, and if they have the ability, I must have missed it.
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
I think merging is the achilles heal of CVS. If indeed merging 'rocks' with Preforce, this would be great news indeed. Could you provide more specifics on the merging process and how it differs from the cluster f... of CVS? Thanks!
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?"
A nice auto-merge would be nice. VSS does this fairly well. If it can't figure it out, it asks, which I think is far preferable than messing up my source. Lots of commercial tools don't do this terribly well.
Also, a utility that can handle branching and merging of source trees, would be nice. I haven't run into a single source control program that doesn't have its quirks in this area.
The big problem with any open source CVS replacement is going to be acceptance and stability. I use CVS because it's been around forever. It is going to be quite a long time before anyone starts using a new system, simply because no one's going to want to gamble with their source code.
I think the key to getting the development community to use a CVS replacement will be a strong set of unit and acceptance tests to accompany it, but even with this, it will take years before most people are willing to switch over from CVS.
http://aegis.sourceforge.net/ Open source, integrated compile, build and test, distributed repositories, internationalized, branching, etc. "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. "
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.
Absolutely the human management of the development team counts for much more than the tools.
When last I left Lucent Wireless they where on their third go-round trying to relace the old primative Sablime version control system, (developed in-house at ATT), with Clearcase. The productivity of some of the Sablime using groups was really quite good. Those were the groups with smart managers.
One note of interest, however, is that Rational's make utility, Clearmake, was distinctly inferior in performance to Lucent's in-house nmake, (not to be confused with MS nmake). The decision was made to stick with nmake even in the Clearcase projects even though some Clearcase functionality would be sacrificed.
"Obtuse Anger is that which is greater than Right Anger" - Lewis Carroll
- 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.Continuus (http://www.continuus.com) redirects to Telelogic.com because Continuus (Irvine CA USA)was just purchased for $42 by Telelogic (Malmo Sweden).
I did a white paper on configuration management while a consultant at a ... fortune 500 retailer Se**s.com (home of cr****man tools and Ken***e appliances). I evaluated version control and bug tracking combined ('config management' embodies these two functions).
In any large software project, the issues of bug tracking and version control are very, very tightly interwound. With 100+ developers and 20+ quality assurance (qa) testers, we'd get lots of both bugs and fixes. The trouble was how to associate the two. I built some tools for short term use (that are still in use) using (ugg!) PVCS (not polyvinyl chloride :-) ) and a custom built bug database. We'd associate a checkin of several files with a bug number, promote them to(copy 'em into) the qa dir, send a email to qa, and allow qa to approve the change by bug number not by file number, which promoted (copied) them to the production-level directory. Its a pretty smooth system for something we developed in-house, but it would have been nice to have a web interface, and all the bells and whistles that a purchased product would provide.
Building this was a pain in the butt. Continuus does this, as does Rational, but they are both hideously expensive ($300 - $500 per seat). There were some also-rans (close competitors that didn't quite work right or satisfy the criteria).
The big deal was getting something in house fast. The more money it cost, the more time management took to decide (they still haven't). What we (in the open source community, and Linux in particular) need is a toolset that integrates bug tracking and version control tightly. It really multiplies programmer productivity because the time they don't spend copying files for a custom build. QA is happy because they're assured a bug goes away, and that the tests they run can be regressively associated with a bug number and therefore with a set of files that work together, not one at a time.
If I get time, I'll post the white paper that I wrote specifying all the criteria for config management. There's a bunch of config managment links on my homepage at justanyone.com.
Unitarian Church: Freethinkers Congregate!
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
I don't understand what subversion does when brancing that you dont like? Please elaborate?
But you could add new features to it, or yet
another co-existing product.
I think the main problem is that what you do
with your software beyond CVS' source code control is generally so customized that there
hasn't been a unified project to handle it.
The ideal version control system would only be found when you needed use it's administrative function (releasing version, comparing versions etc.)
During development, you shouldn't even know it's there.
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
Yep, they started using it with Windows 2000. They call it SourceDepot, but some Perforce commands mention SourceDepot. Maybe a custom version of Perforce? They sure as hell don't use VSS...
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
Subversion keeps track of the repository states and versions them instead of keeping versions on separate files.
This paired with atomic commits of (multpile) changes should do it for you, right?
Over the past couple of years, I have started to become a Disciple of extreme programming (silly name, great concept). I envision a system where many of the features of XP are integrated with the revision control system. Essentially, code must have tests and modicum of documentation (a paragraph explaining what the hell is going on would suffice).
At a slightly higher level, integrating the requirements ("stories" in XP speak) into the system would allow better tracking of progress of both subsystems and parts as a whole.
For example, a project starts with 50 "stories". In the first few weeks, 30 stories are completed (i.e., code exists with tests which statisfy each of the stories). The customer (or managers, etc.) could bring up a story and review all the unit tests, acceptance tests, etc., for a particular story. Should the customer discover a new special case, they can extend (or append to) the acceptance tests for particular story (or set of stories). In this way, nothing gets left out or overlooked and every part of the system is verified automagically. (Plus, the programmer gains a bit of safety from poorly specified projects.)
As the number of outstanding stories decreases, projection can be made as to project completion. Stories which are getting left behind can receive additional resources, etc. The revision control system could actually answer the age old question "is it done, yet?".
Anyone what to help me write this?
(I have actually spec'ed some of the system out, but I have been too busy to do anything about it...)
The real silver bullet to good programs is caffeine; lots and lots of caffeine! *twitch, twitch*
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
I missed my caffine today so I'm a few brain cells short.
Perhaps I should clarify my former (soon to be) flaimbait.
First off It'[s knee jerk reaction to project splits. I don't like seeing projects split unless politiaclly there is no other option (like the maintainer is a source code greedy jerk). So I'm some what aggitated by news of another version control. Especially with spening such great effort to fight the CVS battle against VSS and the like. And when the de facto standard of CVS came about I thought I had won.
Secondly, I do feel changes need to be made. CVS is limited and enhancment are required. (But what open source project isn't). The subversion successor sounds fabulous and I will download and try it perhaps even use it in production. However It bothers me as to why it's is a sepereate project. Subversion or CVS v2.0 or CVS (Subversion) v2.0? I don't see why a completely new project is required.
one of the ideals of a hacker is you should never solve a puzzle twice. So now Subversion is reinventing the CVS wheel to make it better when it could just make CVS better. See my delema?
Anyway maybe there is a good reason hiden there. that's why comment welcome. And none of these are intended as flamebait thay just sound that way. Sorry.
> SELECT * FROM brain_cells WHERE synaptic_rate > 0
0 row returned
TortoiseCVS
The database idea is just what Atria/Rational did with Clearcase. The CM package sits on top of an Oracle database (VOB) and integrates it with the filesystem.
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.)
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.
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!
It doesn't go to the detail of implementation, but could be a meta-model to compare/contrast versioning system implementations.
This model also support policy based version to version link resolution: stuff like fixed version, latest version, version from same context...
Some other comments have indicated that a versioning system should have better dependency tracking. I've extended the SnapCM model to Versioned Hypderdocuments (XML plus XLink) as one example of precisely recording dependencies. A programming languages import statements could be treated the same way.
I think most people are confusing revision control with project management.
For that we already have make.
RCS and make are all you need, with ssh to make it network friendly. Isn't that the Unix(tm) way?
We don't need a 'GNUSourceSafe'. Does anybody put checkin and checkout targets in their makefiles anymore?
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.
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.
tkp4 is a very good clone of the Windows p4 gui.
:)
http://web.cuug.ab.ca/~macdonal/tkp4/
I open it up now and then when I can't translate a concept from CVS in my head.
-- The world is watching America, and America is watching TV.
You described WebSphere Studio, among other systems. It works well if you license it for everyone that could ever work on the code. Very nice if you're deploying to WebSphere. Leave the family and it's just annoying.
We're using AccuRev for Linux and Windows development. The features are great - multiple stream hierarchies, giving each developer control over what and when he promotes or gets. Integrated bug tracking is nice. Unfortunately, the company is small, and the tools show it. Bugs abound. The java front end is quirky, but at least it runs on an X server or on windows (although is is too slow to tunnel through ssh).
Because disk spae is cheap, files are stored uncompressed and undiffed in a directory hierachy, which is a comforting thought --in case the whole system has a meltdown.
I hope the company is successful, because AccuRev has a lot of potential, IMHO.
Cleartool does indeed have a subcommand for marking an element as deleted while preserving its history for later recovery ("cleartool rm"). However, it does not have a simple command to do the later recovery. For that, you have to manually root around in the "lost&found" section of the vob, which is a major pain in the rump. This is especially painful when you run "cleartool rm" on a directory but not on any files or subdirectories inside it.
My general feeling about ClearCase is that it makes just about every SCM-related operation possible, but many of them are needlessly awkward.
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.
Check out the free clone of clearcase that is being developed in Australia...
It is called Katie and it is written in Perl.
http://www.netcraft.com.au/geoffrey/katie/
Enjoy!
Check out this article I had written a while ago.. It might give you some ideas.
/ 01/31 /CVS.html
Easing Web Application Development with CVS
http://linux.oreillynet.com/pub/a/linux/2002
Oktay Altunergil
---------------
Founder of the The Free Linux CD Project
(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
ccache.samba.org
Please note that Subversion is designed as a set of layered libraries. We are also implementing language bindings to those libraries (via SWIG). At the moment, we have Python bindings to most of our libraries.
This scripting support works from the low-level access to the versioning database, all the way up to the high-level client library. (the command-line client is just a thin app glueing stdin/stdout/stderr and the cmdline to the libsvn_client library)
The command-line client app also ensures that its output is machine parsable.
You want scriptability? Hoo. Subversion has it.
[ I'm just waiting for somebody to take the Python GTK bindings and the bindings to the client library to build a cool GUI app ]
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.
I work for an unnamed big company that has converted to clearcase. On the other hand, I invented various excuses to keep CVS for my group. The other people on my floor are not having fun. They have to check out every file they change in advance rather than just letting source control figure out what they have changed. Then they have to check in each file a lot of times - to their private branch, then to shared branch and other places I don't understand. To merge the file, they have to look at some mind-boggling chart with dozens of boxes and prolifiration of arrows. The central server constantly goes down and for a few days they get to do source control with floppies. When it is running, ct co -nc filename takes anywhere from 2 seconds to 1 minite. We never had a fulltime source control admin when we used RCS - I just used to write a new shell script once in a few month when they wanted some new feature. Now we have a fulltime admin and even people who used clearcase for 3 years talk to him every few days. In my life, I only saw a few pieces of software that were so screwed. This one has earned a place in my heart (or somewhere) right next to RealOne player, DOS 4.0, Solaris 2.1 and Thexder 95. If they make me move to this thing, I'll just set up a shell script to zip my cvs repository every week and check it in to clearcase.
I've used StarTeam and CVS. StarTeam is fantastic, 'tho expensive. It is very, very, very useful to tie bug tracking and change requests to version control. This makes it easy for an organization to see how a product is progressing, and to track the history of changes vs. bugs. This is particularly critical for folks who work under ISO9000, FDA QSRs, and other such regulatory regimes. It is also super-useful if you are not working under any regulatory regime other than your customer getting ticked when important bug fixes or new features fall between the cracks. Starteam is a GUI-based system that integrates version control with bug tracking and change requests. It is intuitive, powerful, and reliable. (No, I don't work for the StarTeam folks)
We have yet to do some throrough analysis of Subversion's performance characteristics, but we're quite hopeful. We've built the code on a number of tools that should give us excellent headroom for scaling it up.
First, the repository itself is based on Berkeley DB. Very fast, transacted, capable of hot backups, etc. Unfortunately, we can't really scale this across machines, so (until we get a traditional relational backend) we'll reside on a single box. But given its maturity, its use of shared mem to coordinate multiple threads/process, I think we're going to be able to make great use of it to scale up and (well) across a multiple CPU system.
Next up the design stack is Apache 2.0. We can scale this through threads and processes in whatever way fits the machine and operating system the best. We've got process preforking, fixed thread pools, or dynamic groups of processes and threads. It works on "all" operating systems out there, taking advantage of the characteristics of that platform (there are custom processing modules for Windows, OS/2, BeOS, and NetWare, plus the standard set for Unix and its variants). Compared to CVS which forks multiple processes each time you connect (2 via pserver, or 1 SSH + 1 cvs via ssh), Apache just has processes/threads waiting for processing.
Last up the stack is caching proxies. Since the network protocol is based on HTTP, and we have made use of WebDAV/DeltaV, we have a firm specification on how to mark resources as permanently cachable. For large sites like SourceForge, where a huge amount of the traffic is anonymous checkouts, having reverse caching proxies "in front of" the Subversion repository will offload a lot of the work of delivering basic content down to the user's machine. Workgroups can also install caching proxies at their network edge (or even within their department) and access remote repositories through it. The first guy in who does an "svn update" will prefill the cache, making updates for the next people operate at LAN-speed. For geographical disperse teams, this will be a big win.
The streams and management features are an add on package called UCM. Its all about turning code into assembly line work. It will never work but people try anyways.
If you take all that crap off the top of ClearCase and you have *skilled* workers, nothing can beat it.
Its unfortunate that so many of todays coders belive that the SDK IDE or other uneccesary feature helps them. If you have this type of devveloper on your team, it doesn't matter what VC you use.
yah, I am a coward
Subversion has a CVS converter (partly done; it converts the main trunk of a repository, but no branches or tags). I would be very interested in throwing it at your CVS repository to see if it works. The RCS parsing is performed using ViewCVS's tools, so if the latter works on your repository (specifically, the annotate/blame functionality), then cvs2svn ought to work.
:-)
:-)
We've also been doing some testing with portions of the GNU tool chain CVS repository. That is definitely an old repos
Before we declare cvs2svn "done", we'll be throwing the entire GNU repository and the ASF repository at the thing. When it passes, then we'll consider ourselves done
At my work it takes 3 CC person to support a gang of 110 developers. I guess it's just a question of how good your 5 guys really are, and how well your developers stick to a common protocol.
Only branches from no more than 2 labels behind!
Labels are only created by one person, who resolves all merge conflicts with the developers.
My 2 cents.
Yes, but "over SSH" means that you have to pass out system accounts to everybody who needs to commit to the repository. This specific problem with CVS over SSH blew up SourceForge, and they had to switch over to a PAM/LDAP system to handle the account load.
Subversion doesn't require system accounts. Its authentication is handled by Apache, which means it can tie into any sort of account database. Flat text files, LDAP, MySQL databases, Kerberos, NTLM, or whatever. With SSL for encryption and client/server certificate verification, you've got the security meeting or beating SSH-based access.
We're using a set of tools from Synchronicity called DesignSync/ProjectSync that have revision control, collaboration and problem tracking integrated together. It's aimed primarily at chip development companies, but some of the features are pretty cool. They use an Apache webserver to interface to both a commercial version of RCS (called RCE, IIRC) as well as a database for the problem tracking/collaboration system.
One of the features we like is that revision control operations create entries in a "revision control note" (in ProjectSync, the collaboration/problem tracking portion of the tool) which can be queried just like any of the other note types. It's much more flexible and useful than just having the ability to query a file for its revision history.
Also, we can attach links to specific file versions in the vault to a problem report that's being closed; this has been very helpful in maintaining project history. Everything in the vault has a URL, which is a great way to reference the data.
I mention this only as by way of the features we've found useful, not by any means a suggestion to use this for software development.
- Leo
You don't use science to show that you're right, you use science to become right.
The ability to say "move this branch back to the way it was on 8th Nov and forget everything after that" without starting a new branch would be good.
Handling links is a must too.
A further nice option would be "these file extensions are always binary unless stated otherwise".
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Does that mean that you can't use it as non-root user to make a private repository somewhere in your home directory? Or you can do it, but only by having a private server process running on one of the user-accessible TCP/IP ports (instead of just having a program running during checkins/checkouts etc.)?
The Tao of math: The numbers you can count are not the real numbers.
Perforce Praises
Perforce Gripes
- Sometimes, the perforce server crashes and/or becomes unavailable (ours runs on Windows, unfortunately). CVS allows disconnected operation -- you can edit files without having connectivity to the server, and later commit your changes. It doesn't matter if the sever has crashed with CVS -- you can still get work done. With Perforce, it is difficult.
- Speed. Speed. Speed. The Perforce protocol is very fast, but our perforce operations go very slowly because of a slow net connection to the remote server. Checking out and commiting large files takes up to a minute per file. When checking out a depot for the first time, it can take hours. If the server were local, it would go faster. Long running operations in perforce lock out other users. In our large company, this means that perfoce users must wait around. Obviously, the distributed nature of BitKeeper solves this kind of problem.
- p4 sync doesn't show files in your local sandbox that aren't in the repository like cvs update does. This sometimes results in broken builds because people forget to add files using p4 add.
- p4 sync doesn't re-get files that are deleted from the local sandbox like cvs update does. And p4 sync -f regets all files, whether you already have them or not.
- Minor gripe: Perforce branches are copies, which is a less-effective use of disk space when compared to CVS.
- Disconnected operation. CVS is designed to let you work on code, disconnected from the CVS server. When ready, you can commit all changes. With perforce, you are forced to have connectivity to the p4 server to edit and change code. This slows programmers down when the net or the p4 server is slow. It also makes it difficult to work on code on a laptop.
I expect that BitKeeper and Subversion will solve all of the problems with CVS and Perforce. I expect Subversion to blow perforce out of the water. Unfortunately, my company has invested major time and money into Perforce, and I don't think we will be switching anytime soon.http://subversion.tigris.org/
Your all right. Perhaps I will take my head out of my ass. What good does complaining and bickering do anyway.
So the real question is how can I help subversion and get it up to CVS expectations politically? Hmmm I think I'll read the TODO list tonight.
Thanks all.
> SELECT * FROM brain_cells WHERE synaptic_rate > 0
0 row returned
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
You want scriptability? Hoo. Subversion has it.
Does that include running a script after a check-in? What about tagging revisions?
What I'd like in the ultimate VCS is the ability to run a compile on multiple platforms, and tag the revision based on success or failure. Then, if the compile succeeds, I want it to run one or more regression tests. When I synchronize my local copy with the database, I want to be able to sync based on the latest version matching some set of criteria, such as "latest that compiled on my platform", "latest that passed regression level 1 on all platforms", etc. Is Subversion aiming for support for anything like this?
Perforce, BTW, supports some of this. However, I don't know if it can conveniently support syncing based on some criteria, rather than always getting the latest.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
For your scenario, I suspect what you would want to use are "revision properties." Each revision that gets committed can have (arbitrary) properties associated with it (and the properties are not versioned). Thus, your post-commit script could kick off your build farm. As each build completes, you can add a new property to the revision. When all are complete, then you kick off the regression tests. Upon a pass, you add a final property (and possibly remove the build props).
At this time, however, and it isn't on the plan, is a way to update to a revision that matches a particular query. However, a CGI script could easily be written which would query this on your SVN server and return the specified revision. You could then update your working copy to that revision. Heck, you could write a client-side script that would connect to the server to do the query, then pass the result to your 'svn update' line.
So I'd say the data model is there, but the wrappers you're looking for are not built in. But due to SVN's great scriptability and library-based design, you can easily grab and/or modify the data you need.
http://freshmeat.net/projects/mcvsf ootprints.net/~kaz/mcvs
http://users.
That is a psychological problem, not an
actual tool problem.
Scrambling right before the build is a process problem, not a ClearCASE problem. Put all your bug fixes on branches, and only allow the CM team to merge in fixes to the project mainline. Developers are responsible for notifying the CM team (through email or some bug tracking tool) that their branch is "ready to go". Official builds are only done in the one official CM view. Really, the view shouldn't be an issue at all; every build view's config spec should just be the previous build's label (you are labeling every build that you release, right?) plus the fixes for this new build. Your total time to do a build is just the time to have a meeting and agree which bug fixes you're picking up, the time to do a (mostly-automated) merge of all the branches to the project mainline, the time to actually run the build, and maybe some verification at the end before you release it. Oh, and writing release notes, which can be pretty much automated as well. ClearCASE is built for scriptability and automation; learn to use it and it will save you so much time and help avoid so many simple errors.
ClearCASE can be seriously screwed up by bad admins; five admins for 50 coders indicates to me that at least four of your admins didn't know what they were doing :) One admin, part time, should be good for 100-200 developers, unless you're expecting that developer to also be developing extra "gravy" like reports and ClearCASE trigger scripts.
Your right to not believe: Americans United for Separation of Church and
- File versioning
- Change requests/bug tracking
- Task delegation and tracking (for distributed development teams)
- Topics (kind of like a Usenet newsgroup, complete with threads of discussion
- The ability to link revisions of files/change requests/tasks/topics to others (we're talking any revision in any category linked to any revision in any category)
- Labels, for tracking file revisions, etc. in particular builds
- Floating promotion states (indicating which label is currently the development version, this one is in testing, this one is released, etc.)
- Views, which can provide subsets of projects (does every developer need to see the ENTIRE source code base?)
- Sharing between projects (very nice for taking a base project and spawning customized versions)
The newer versions (5.1+) also provide integration with a Requirements Management tool (kind of like Rational Requisite Pro).It isn't cheap, but man, it's ALL there. There are GUI AND command line clients, for Windows and for Java, plus a complete Java API for scripting tasks and reports.
Seen in the readme.txt for DB2 Personal Edition for Linux:
Linux is a trademark of Linux Torvalds.
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.
Key point being that CMVC has "defects and features". These combine the tracking of a defect tracking system AND change packages. ANd it has a process. For large system development you can't beat that combination. CVS is great for small stuff :-)
Subtle but important difference - cvs *can* support the "Lock Modify Unlock" model as another poster has noted, however, you are really going against the philosophy of CVS, which is based on the Copy-Modify-Merge model. Take a look at Karl Fogel's excellent book (some chapters available on the web) for more information on this.
http://cvsbook.red-bean.com/cvsbook.html
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)
I'm sure there are some great improvements to be made to CVS, but you're reasons are mostly user error. I suggest you take a look at the documentation that other posters are suggested
.CVS instead?
./src/ -name "*.java" | xargs -n 100 | cvs add' just to hunt bring in my new source code.
1. Documentation is piss-poor. There's an easy solution to that one, but nobody likes writing documentation.
-- see other posts - there is great documentation.
2. Updates don't always work as expected. They won't grab new directories and a few other quirky things.
-- I'd call this user error. You need to add new directories, just as if you are adding files. But I agree it's a little awkward.
3. Empty directories should be pruned by default in a checkout or update.
-- I use WinCVS, prunes by default, you can change the setting in a dialog box, simple.
4. I'm tired of seeing a CVS directory everywhere I look. How about
-- Maybe. But this is part of the simple power of cvs. I can easily check everything in, delete the whole directory structure, and check the project somewhere else without some registry or other problem (think of what a mess it is to delete programs from Windows).
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.
-- CVS passes off access control to the operating system. Again, CVS has a nice 'Unix' design in which it builds on existing utilities already available in unix (RCS) and the 'everything is a file' idea is similar. Thus, complaints that CVS is hard to use are true, but this is part of the design philosophy. Perhaps we need to wait for an operating system where 'everything is an object' (Yes, I saw Andrew Tanenbaum at a Comp Sci lecture a few years ago..)
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.
-- User error (if I understand the question) - CVS follows the Copy-Modify-Merge philosophy, not Lock-Modify-Unlock, although you can 'lock' files. See answer to 5 as far as authentication also.
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.
-- totally incorrect. One of the reasons why cvs is the 'defacto' standard is it's incredible support - JBuilder, Eclipse, to name a few, have built in support, otherwise there are tools to support this such as Igloo. Note that IDE integration with any version control system is always an issue (at least the products I've used..)
Developer
8. Needs smarter add functionality. I don't like writing stuff like 'find
-- there are some *great* gui's available, for example WinCVS.
9. CVS is a boring acronym.
-- so what, we should get the Microsoft marketing team to dream up a catchy name? Do you want a neat icon too?
10. I can't think of a tenth thing.
-- given that list, then I'd say CVS is awesome, huh?
API, API, API. And I don't just mean some pathetic wrapper function or two that only allows you to make a module that says 'hello world!' without having to get in there and custom design the whole damn thing yourself (thus making you ask... "why the hell didn't you just tell me the architecture and let me design my module from scratch in the first place?") I appreciate choice in apps.... but what I don't need is a slew of apps that each are different but are incompatable (or would require a crap load of redundancy once integrated) Hmmm, ok this sounds bitchy I guess. Just tired of hard coded apps that you can't plug together in a usefull fashion.
No database please. The main thing i love about *n[iu]x is *everything* is in a file and there are thousands of nice tools to do everything you can imagine to files.
I know, a database sounds nice, but i have worked with a database based CASE tool at work. While the tools is ok, it is a real pain to do omething
that is not supported within the tool.
( We are talking about a few thousand pages
of documentation for QMF ( Query Management Facility ) Queries! )
A ClearCase-like system for Linux: Katie
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.
CVS annotate shows you who merged a change from one branch to another. There's no support to tell you automatically who made the original change.
If svn does right all the things CVS does right, and svn annotate gives you a choice of looking back past the merge, into the source of the original change (which should be possible because it has meta-data to enable repeated merges) then I would like that feature.
I thought this might be a good time to get a feel of what's out there. Some classmates and I have created a generic interface to multiple version control systems. (Perforce, CVS so far...) We haven't really looked into how useful this might be. The software has been designed to let people write their own plug-ins for different systems. Whatcha think? b.
The natural architecture for a system writen in Ada93 lends itself very well to version control. In addition it is far superior to many other languages for large projects with distributed developers. The only other language that comes close ( very close in some characteristics) is Java.
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)
Okay, this is to all those self righteous arrogant sons of karma whores who mod downs posts because they make any sort of positive reference to the Evil Empire (for all values of Evil Empire).
The post to which I replied attempts to defend CVS almost exclusively from a social viewpoint (uptake and support), while ignoring the technical shortcomings in the product. This is exactly the argument that the Open Source movement as a whole makes against Microsoft, a point which I illustrated through parody.
The argument that something is good or good enough simply because of widespread acceptance doesn't hold water. At best, CVS can be said to have been the best system available at the time. That in no way makes it a superior solution to full-blown configuration management systems.
So next time, think before you press your Troll hot-key, because just maybe the author isn't some 2 bit skript kiddie try to elicit a response from your sorry little back-room unix wannabe guru who has never worked on a Microsoft system but will claim it is shit anyway mind.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
In the past, I used Emacs's VC features extensively. (This is the front-end over version control systems.) Now, I use both PCVS (added in Emacs 21, takes advantage of CVS's features) and VC extensively.
It's great. I wanna work on a file? I open it, press C-x C-q to get the latest version. I edit it, then press C-x C-q again to check it in. If there was a conflict, I get an easy to use conflict resolution browser. I fix it, and commit again. I type in a log message (viewing the diffs to help me by pressing C-x v =), press C-c C-c, and I'm done. All that is under VC. It's easy as falling off a log.
PCVS adds the ability for me to quickly look over directories to see what the status of different files is. From there, I can mark files and perform batch updates.
Post-failure analysis is easy too. Annotate, diff, log, etc. are all available at the touch of a button while I'm editing the file in question. Nothing to it.
I see a lot of people who don't realize how easy these can make CVS to use. I use CVS all the time, and have no complaints.
Take this example:
:-)
In order to streamline your code, you want to put a function in one of your sources more to the top. If you checking this in with a textbased RCS, you will get two changes:
- newly written code on the top
- deleted code on the bottom
, which is hardly what you actually did to the source (Not sure if every RCS is so dumb
Compare this with a graphical programming language, where your code is inside graphical blocks: when you move your code around, the blocks gets a new position, but its content is left unchanged. A RCS for such a language would only need to update the "position", making the checkin not only smaller, but a graphical tool could display the changes made in a much more relevant way.
Hmmm, looks like a cool business idea...
Just a couple of responses to the above:
2. There are some ways to alleviate this problem, but bitkeeper addresses it directly as you say
4. You can do this with "p4 diff -sd | p4 -x - sync -f" or in a few other ways
5. Branches are copy on write which is pretty efficient.
6. There is a Tech Note showing how to do this.
Subversion seems to be reinventing various Perforce features (which is the right thing to do). It has a long way to go and isn't advancing that fast. I don't expect it to blow Perforce out the water any time soon.
Is deletion of directories from the repository and it really ticks me off to no end. We have the same cvs repository for all of our companies documents and projects sources, so you can imagine how over the years it bloats and bloats and not being able to clean it out properly really sucks. For that matter a recursive removal of directories and contained files would pwn too... Oh and by the way, for you wind0ze users, install TortoiseCVS, it simply owns. //Miqlo
David , it sounds like you were working in a team full of pretend CCadmins and engineers. Obviously nobody had even read the manual !! I blame teh management for allowing this to happen . You sem to blame the tool ...
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"!Thus, your post-commit script could kick off your build farm.
I'd probably have my build farm machines each running a script, checking for new commits periodically, instead. That way I can just add or remove machines as needed, with different hardware/OS/language combinations, and not have to bother the server. But in general using the revision properties sounds like just the ticket.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
There are lots of posts on Clearcase, Aegis, Perforce, etc. Anyone have any opinions on ChangeMan, Dimensions, and TRUEChange for the following:
-- Enterprise level - 1500 developers, hundreds of projects
-- Distributed development
-- Process driven
-- ability to tailor process levels for various groups
-- ability to script against and integrate with other tools
Thanks!!
As far as "advancing"... well, to be honest, we pretty much finished the core of day-to-day usage last fall. Since then, we've been rounding out the feature set and stabilizing the code. People need to trust Subversion to hold their source code safe. We don't want to give them cause to question SVN, so we are giving ourselves plenty of time to get it right.
Our Alpha release is next week. Most people would call it a Beta release, but it goes back to the stability thing. For our purposes, it is alpha. Trust is hugely important.
Fair enough. Note that it will be much easier to do this because of the global revision number. You can fetch the head rev num (simple and fast) and compare it against what you last built. With CVS, you'd have to crawl the entire repository looking for changes to rebuild.
:-)
To print the head rev:
$ svn stat -un . | sed -n '/^Head/s/.*: *//p'
There might be some other nifty ways. Especially if you write a script that binds to libsvn_ra. There is an RA function to query the head rev.
fun fun
User ClearCase Multisite. You can distrubute the load over several servers whether they're in the same room of across an ocean. I currently admin servers in Chicago, Detroit and Munich.
Not only that, but you get awesome redundancy. we have some projects that we multisite to different sits just as a hot-backup measure.
Blaze a trail to the New World
Crossroads NEWS - July 2002 A Monthly Publication for SCM Professionals Register and win a Handspring Visor - http://www.cmcrossroads.com * * In this Edition - Salary Survey: Java Still Hot - Key Keppler - JAVA Pro - Behaviorally Speaking: Defining the Software Development Life Cycle - Bob Aiello - The Carrot Works Better than the Stick - Matthew K. Johnson - Make your own best practice: The ACME Process - Bridget Pilloud - Avoid Role Name Confusion - Charles Edwards - News and Events - Tool Spotlight - Book of the Month Read this edition online - http://cmcrosroads.com/newsletter/julnews.shtml * * * Editor's Note Over and over again you hear all the ways to improve the reliability of software applications and the development process. Every one has THE product, solution or process that will do it all. And if you install it or use it, all your problems will go away. I've tried many, used a few, thrown some away and marveled at the complexity of yet more. When asked by an organization about the best way to go about implementing a new tool or process, I sometimes just have to ask a question in return. How do the people that are doing the work feel about your new tools and process? Do you know how your developers use the tools they have today? Are they trained to use them? Are they all happy in their current work environment? In many organizations, it is as simple as the tail wagging the dog and there are other questions to ask. Does the management in your company set the business goals or is this the responsibility of development? Are all the people in your development teams aware of the business objectives behind the software requirements? Like it or not, it is the role of management set the course, and the role of development to pull on the oars. It is also however the role of management to listen to their technical experts and to make sure that the development teams have the right tools to get the job done. Are those things in the water oars or garden rakes? Too often we forget that there are many things to consider besides the cost of the software, product features and the process you are trying to implement. We have all heard countless company CEOs state that their number one assets go home every day, but I wonder today how many organizations really recognize this fact or even believe it. This month we take a look at the human component of application development and focus on some of the factors that we should all consider in addition to the features of each vendors product. As always we would like your input on the human factors of Application Development. Cast your vote on the subject in our current Crossroads Poll at http://www.cmcrossroads.com or participate in a discussion on the topic in the Community Forums. Patrick Egan - Editor - patrick@catsyscorp.com * * Salary Survey: Java Still Hot Kay Keppler - Editor of JAVA Pro Magazine Go figure--in a year when the economy dragged, unemployment boomed, cutbacks reigned, and profits soured, Java programmers made more money than ever and worked less to earn it. No wonder they're a happy lot. The Java programming landscape is quite diverse, but some skill sets pay better than others. Are your skills putting as much money in your pocket as they could be? Read on. In our 2002 career survey sampled Java programmers' work and compensation and compared it against geography and gender, education and training. The results--starting with total remuneration--were perhaps surprising, given what we've come to expect from a squeezed economy and lowered expectations. Last year, the programmers we surveyed in the United States earned on average $83,000, but this year the average total compensation--salary and benefits--of our sample was $93,500--11% more than last year. Read the full article online - http://www.fawcette.com/javapro/2002_06/magazine/f eatures/salarysurvey/default.asp
* *
Behaviorally Speaking
Defining the Software Development Life Cycle
Bob Aiello - Contributing Editor
Defining a Software Development LifeCycle (SDLC) can raise many behavioral or "people" related challenges. Any effort to specify how people should work is bound to meet with extensive resistance and even hostility on the part of the developers who must adhere to the development process. Yet it is essential that the successful CM Practitioner create a release process that is repeatable and predictable. Tremendous losses can occur if a major company has production applications that cannot be quickly fixed because they do not have the exact sources and build dependencies safeguarded and available. In this article we would like to look at how to create a useful SDLC that specifies the workflow necessary to support the Software Development Process, especially Release Management.
Read the full story - http://cmcrossroads.com/newsletter/articles/bajul0 2.shtml
* *
The Carrot Works Better than the Stick
Matthew K. Johnson - Contributing Editor
Can I please see a show of hands on how many configuration managers out there want to yank their hair out by the roots trying to get people to follow your configuration policies and procedures? OK, I see just about everyone has their hand up, all except for the guy in the back row who is probably playing Mine Field on his PDA. You spend a lot of time and putting together Software Configuration Management (SCM) policies and procedures to improve the overall efficiency of your development team just to find your efforts are de-railed when it comes time to get people to follow them. Are your policies really that bad? Possibly, but most often the real problem is good old human nature. People don't like change and don't like to be told what to do.
Read the full story - http://cmcrossroads.com/newsletter/articles/mjjul0 2.shtml
* * News and Events
Borland Enterprise Studio 4 for JavaT forms a Complete Java Development Solution in Single Package http://borland.com/news/index.html
MERANT Collage now available. A powerful and easy-to-use enterprise content management solution for application-driven Web sites. http://www.merant.com/PVCS/press/index.html
AccuRev 3.1 includes a new integrated graphical diff and 3-way merge tool, patch-tracking, side-by-side visual image diff, promotion by transaction, new triggers, Forte for Java IDE integration. http://www.accurev.com
Code Co-op 3.3 - A version control solution for individuals and teams that joins developers residing in different locations using only email. http://www.relisoft.com/co_op/index.htm
August 12-15 - Linux World Conference - San Francisco, CA - Moscone Convention Center - http://www.linuxworld.com
August 18-22 - Rational 2002 User Conference - Orlando, Florida - http://www.rational.com/events/ruc/
September 3-6 - Quality Week - San Francisco, CA -
http://www.soft.com/QualWeek/QW2002/
October 1-2 - Web Services Development Conference - New York City - Jacob Javits convention Center - http://www.wsdevcon.com
October 13-18 - Starbase annual global user conference. San Diego, CA http://www.starbase.com/events/symposium/
October 20-23 - Telelogic Americas 2002 User Conference -Las Vegas, Nevada - http://www.telelogic.com/news/usergroup/conference s.cfm
* *
Make your own best practice: The ACME Process
Bridget Pilloud - Contributing Editor
Albert Einstein's housekeeper would hang an umbrella on the front door knob, because otherwise he'd walk out in a downpour and not realize it was raining until he was halfway to his office and soaking wet. One of the greatest minds in history, and he didn't have the sense to come in out of the rain.
Working in development is like that. Brilliant, creative people focused on a specific task, oblivious to everything else going on around them. As a configuration manager, your job is to support them, to keep the bigger picture in mind, and often to find better ways for them to work. For whatever reason, if you find yourself tasked with making your development world a better place, there are things you can do to ensure the processes you develop are relevant, timely, and even appreciated.
Read the full story - http://cmcrossroads.com/newsletter/articles/bpjul0 2.shtml
* *
Avoid Role Name Confusion
Charles Edwards - Contributing Editor
Don't you find it confusing when you go from one company to another and find all sorts of different names for similar roles people play in the IT software development process? I've had heated debates with people only to find we were in violent agreement and it was the use of different terminology that was causing the incorrect interpretation, because we were ultimately both trying to say the same thing. This doesn't only happen with Roles and Activities on projects but with many different terminologies meaning the same thing!
Read the full story - http://cmcrossroads.com/newsletter/articles/cejul0 2.shtml
* *
Book of the Month
Software Release Methodology
by Michael E. Bays
Shows you best practices for every stage of a successful product release. Includes carefully designed, practical solutions that enhance quality, reduce costs, and get you to market faster.
Software release methodology is a field that unifies a number of previously abstract endeavors that occur during software product development. By unifying these abstract endeavors, we provide a more efficient, well-understood path from development to product release. The field focuses on the release activity as the driving force behind all development endeavors.
Purchase or review this book at http://cmcrossroads.com/cgi-bin/links/jump.cgi?ID= 65
* * CM Tool Spotlight
Each month there are 4 development or SCM products reviewed in the Tool Spotlight.
This month we feature: Openmake from Catalyst Systems, Telelogic CM Synergy, MERANT PVCS Content Manager and MKS Source Integrity Enterprise Edition.
Visit the Tool Spotlight at http://www.cmcrossroads.com/toolspot/
* *
Crossroads News is a monthly newsletter published by CM Crossroads an online community for Software and Configuration Management Professionals. If you would like to sponsor this newsletter or any other CM Crossroads Event, please contact us at sponsor@cmcrossroads.com. If you would like us to include your press release or upcoming event in the News and Events section send an email with the details to cmevents@cmcrossroads.com