JDK + IDEA + CVS + ANT = how to make it work?

Engines, Libraries and Tools Tools Discussion
#1

Greets.

So I’m nearing the end of one development cycle. As the game (Age of Storms) nears release, I am looking forward to the next iteration of code, and starting to get a bit confused about some things that I thought I would post for some aid.

So here is what I have decided upon for the development environment:

IDEA 3.0
CVS
Ant (comes with IDEA but is also upgradeable).
JDK 1.3 and 1.4.1

Now, this system has been working acceptably for some months now, but I have some issues that are going to become critical in the next month or so, especially if another developer joins our organization:

CVS - for whatever reason I have crashed my CVS database at least twice in the last six months. I seem to have NO idea how tags and versioning work, and I’d like to be able to get this to work CLEANLY for integration with Ant. This is EXTREMELY important to me and I don’t know where to turn. Books don’t seem to have any information for me. Can anyone provide information on how, during a project, you are supposed to checkin/checkout code and how you are supposed to tag things?

IDEA - this IDE rocks. I have few complaints and plenty of praise (the Find in Path feature seems not to work… sigh…)

Ant - I have only recently begun to understand the power of this tool. Now that I am using Java Web Start, Ant is ever more important to me. I have just gotten build numbers to work using the tag, and I have been thinking about my deployment strategy. I’m thinking right now to leave the script only doing packaging, but with a couple of developers doing nightly builds will be important, so I’ll eventually get it to compile the source from CVS as well. Question is, how should I be doing this with respect to build numbers, and the “build” directory I have which is the directory we store actually deployed code? Oh, and how should THIS build number relate to the build numbers of source code, if at all?

I know many of these things could be relegated to the “up to how you want to do it” category, but that’s why I am asking; I’m not sure what to do, and any direction I can strike out in is a better direction with respect to proper code building/maintenance than I have now.

Thanks for your help.

#2

Not sure if this will help you out with CVS… (I find CVS archaic) but it looks decent: http://www.smartcvs.com/

#3

Thats a great toolchain, it’s what I plan to use on my next project. IDEA being the new addition.

I’m far from a CVS expert but there are some docs at: http://www.cvshome.org/docs/ . The book http://www.cvshome.org/docs/manual/ has some parts devoted to branches and tags but you probably already read that. I’ve read some docs on Subversion and their branching seems more natural but I can’t use the tool because we haven’t moved to Apache HTTPD 2 yet.

My understand is in the Subversion world a branch is made with the “copy” command to a new base directory with a different name. The base directory is effectivly the branch. CVS doesn’t understand name changes of files like Subversion does so you can’t do the same. Maybe thinking of a branch as a copy will help you conceptually. I dunno, you’re kinda on your own here.

As for Ant I like to look at the build.xml files from the Apache group and see how they do things. I figure they would know best. Just get a source archive for any of the Jakarta projects for an example, get a few because some are better than others. As for build numbers, I’d inlcude the developer’s name that did the compile too. Something like:
will help for this.

I’ve been moving towars letting ant do everything from CVS checkouts to compiling and packing release versions. I’ve also been using Jalopy to enforce coding conventions and PMD to point out bad style. Maybe I’m a little too militant about coding conventions and style but I think it’s better than being too slack.

#4

Thanks for the ideas, folks.

Yes, I have read the cvshome.org manual - and I still don’t get it.

I’m looking into Subversion now, and you should know, leknor, that I agree with you. PMD has just been added to my toollist. I won’t use Jalopy as IDEA’s reformatter does the job, and I’m happy with it. The only reason I grabbed PMD is the fact that it plugs in to IDEA and probably does a better job than IDEA’s standard checker.

So does anyone have any ideas on a good place to understand tagging and branching in CVS?

#5

We use CVS and ANT at work, so here is a little about what I know. We use WinCVS as a client on the PC and CVS runs on a Unix server in the lab.

On your local PC you’ll have a copy of the repository, you can make any changes to these files that you like, only when you do a cvs update and cvs commit will you actually change files in the repository.

Each time you do a commit, the version number of a file increases, cvs calls this the revision number. Once you have completed a body of work or are ready for a release you apply a tag to all the code using the cvs tag command. This tag will be “release 1.0” or “test new renderer” or something like that.

As you continue to develop your code and make further changes the version number increases and you can apply more tags, now here is the clever bit, if you need to re-release an old version of your code, you can get hold of it by doing a cvs update -r and then you specify the tag name “release 1.0” and hey presto all your old files are brought out of the repository back to your PC.

Files are never deleted from the repository, when you do a cvs remove (I think) it puts the file into the Attic, this means that you can still build earlier versions of your code, even if that file is no longer used.

I’ve not done any branching so can’t talk about that, hope this helps, if you have any specific questions let me know.

Andy.

#6

I have no experience with IDEA, so I can’t comment on that.

CVS is a very capable tool; I have to warn you that Subversion is still considered unstable! If you’re interested in the extra features it provides, then fine. Otherwise, I’d stick with CVS. :wink:

Get a local copy of Cederqvist; it really does contain everything you need to know about CVS. It may take some time to properly understand it all, so to get you started, here’s a few tips:[]If you’re not using it already, get WinCVS - it saves a lot of time and hassle.
[]Don’t worry about file version numbers - CVS will handle them itself, you never have to worry about them.
[]Don’t bother with Branches - for what you’re doing you don’t need the hassle.
[]Your application build number should relate in NO WAY to the version numbers of files - deciding what version to call your code is your job.
[]You can’t move files between directories or rename them - delete them from one place, and add them to another. :-X
[]If the worst happens and your repository corrupts, Step 1: don’t panic! Step 2: post a “help!” message here. Step 3: search the web and the CVS FAQ-o-matic.
[]Don’t hack the repository! Never edit files directly in the repository unless you know EXACTLY what you’re doing. It takes years of practice to be able to do this safely.In general your CVS process will be (assuming you have a repository ready with some code in it):[]Checkout code at start of project. ;D
[]At start of coding session, run an Update (if working with other developers).
[]Edit code, committing changes frequently.
(It’s a good idea to only commit when things compile cleanly!) ::slight_smile:
[]At end of session, run another Update and make sure other people’s changes don’t break yours.
[]Sleep, eat etc, then return to step 2.If you’re working with others, you’ll need to learn about Conflicts - check Cederqvist for details.

Tags:[]Create tags whenever you like - they’re there to make YOUR life easier, the repository doesn’t care about them.
[]Create a tag whenever you make a release - it’s vital to be able to access the same source code that was in a certain version.
[]Come up with a simple but effective naming convention (idea below).
[]Again, don’t bother with Branches.
[]Create a tag if you’re about to make some major changes - it’s useful to be able to just give up and roll back to the previous code.
[]Restrict tag names to CAPITAL LETTERS, numb3rs and underscores (saves hassle, makes tag names obvious).The simplest scheme for naming tags would be something like using “RELEASE_1_3” for release v1.3, and “BASELINE_0005” for interesting code bases you might want to access later. If you’re working with multiple developers, you might want to tag locations where a major conflict occurred with “CONFLICT_0007” if you’re at all unsure whether things went well or not.

Branching, Merging etc come with their own problems relating to tags, post if you want more information about that.

Oh, one last thing, never refer to the virtual HEAD tag! It’s supposed to work, but I’ve found a few issues with it recently. >:( If you ever need to refer to the current version via a tag name, you should probably create a “real” tag anyway. ;D

#7

Anything we can see of ‘Age of Storms’??

Ah, found it myself…

http://www.ageofstorms.com/

#8

I plan on dumping tons of information AFTER I’ve finalized the code. Makes no point to give out info that’s going to change.

cfmdobbie, that’s some REALLY great stuff; but I wonder, why do you not like branches?

The idea really appeals to me in that I should be able to work on current development, leave that, and head over to bug fixing in another directory if I need to, and merge those fixes in as needed.

Then again, with this kinda thing it seems like you just fix the bug in the current release, and forcibly upgrade everyone.

HMMMMMMMMMMMMMMMMMMM. Potential there.

#9

Au contraire, I love branches!

I can separate out threads of development, experimental work, bug-fix work, enhancement work, “premium” functionality and the like. They allow me to move a person working on changes to a system’s interface onto a separate branch where other people can’t break things and slow him down, and where he can break things and slow them down.

However… They do have a tendancy to misbehave! ::slight_smile:

e.g. “update -A” doesn’t work properly if HEAD gets out of sync with reality. A bug-fix gets made to a branch that isn’t used anymore - and noone can work out where the code has gone. “history” becomes difficult to monitor as while log messages include version numbers, there’s no simple way to translate them into branch names. One small slip and you release the wrong code. Major bugs get fixed on multiple branches, and create merge-hell when it comes to collapse a branch into the trunk. Large structural changes become impossible to merge…

BUT… If you’re happy with using them, by all means go right ahead. Depending on how your working (and the phases of the Moon) things may go fine. :wink: ;D :smiley:

I’ll follow this post with a few hints about using branches…

#10

CVS Branching Hints

General hints:

Still don’t worry about version numbers - CVS maintains them for you. They are not kept consistent over a branch, so watching them is likely to confuse matters!

Never use the virtual HEAD tag. Any time you think you should refer to it, create a merge point, branch point or whatever.

Don’t forget to set “-r” options on checkout in WinCVS - they’re on the second tab and it’s easy to forget them.

Make sure everyone on your team understands CVS and knows what branch they should be working on - inadvertent mistakes are easy to make with branches.

It’s not possible to rename branches like you can tags, so be sure you get the names right before using them!

Performing merges is a complex job. Cederqvist contains a number of good processes to use when merging - they’re worth reading. You can use the automatic “-j” merges, but for the extra paranoid, get hold of a decent diff tool (WinDiff is excellent) and do them manually.

It’s useful for the maintainer of a piece of code to help the CVS admin when resolving merge conflicts. Not always possible with a distributed development team!

Branches + sticky tags = chaos. Try to keep an entire tree restricted to a single branch at a time.

It’s preferable to “release -d” a sandbox and recreate it, rather than performing an “update -A”. It’s too easy to lose data with the update.

Remember that the person performing a merge gets their name against the change. You need to track back through the merge tags to work out who actually wrote a line of code.

Simple naming conventions might consist of a name of the type of branch, followed by the app version number pertaining to it and any suffices to denote the type of the tag/branch.

Example, a bugfix branch created to debug v1.3:Name of branch: BUGFIX_01_03It is often useful to know three things about branches - the point where the branch was taken from, the point where the branch began, and the point where the branch was considered dead:Branch point: TRUNK_01_03_BP
First revision: BUGFIX_01_03_START
Last revision: BUGFIX_01_03_DEADWhen merging, it is also useful to know the point where the merge was taken from, the last version before the merge began, and the first version after the merge completed. These tags relate to the second merge from the branch to the trunk:Merge point: BUGFIX_01_03_02_MP
Before merge: TRUNK_01_03_02_PREMERGE
After merge: TRUNK_01_03_02_POSTMERGE

Well, there’s a few hints. Hope these help! I fully admit most of this is paranoia. ;D
#11

Charlie,

Thanks so much for the valuable information. I have a lot to consider regarding my forward strategy for CVS and I think it deserves CAREFUL thought.

If I may ask, how would you recommend I deal with the current CVS database? I’ve been wondering if it is at all wise to just go ahead and reimport the sources into a brand new repository… and if that’s true, how on earth do you do that and keep sane?

I admit, tagging has been a very hard thing for me to understand for whatever reason. I am still learning to ignore the file tags, and only deal with my own “vendor” tags.

#12

Sorry if this is a bit off topic…but you may also want to keep a close eye on the stellation project (A sub-project of eclipse)

http://www.eclipse.org/stellation/

From their site, here is a brief overview:

Stellation is an advanced, extensible software configuration management system, originally developed at IBM Research. While Stellation provides all of the standard functions available in any SCM system, it is distinguished by a number of advanced features, such as project-oriented versioning and lightweight branching, intended to ease the development of software systems by large groups of loosely coordinated developers.

Things that caught my attention to it:

  • It uses a relational database to store artifacts. Its supports (mysql, DB2, Firebird, Oracle, Postgresql)
  • It allows versioning at the project level. (It should handle file renames and directory changes well)
  • Its free.
  • It provides both integration with eclipse and a command-line interface.

No…its not even in beta yet…No I haven’t actually tried it…but after using Visual Source Safe, then PVCS, and a sprinkle of CVS, this project (when it gets to a stable state) may be what the doctor ordered.

#13

[quote]If I may ask, how would you recommend I deal with the current CVS database? I’ve been wondering if it is at all wise to just go ahead and reimport the sources into a brand new repository… and if that’s true, how on earth do you do that and keep sane?
[/quote]
Is there any reason to drop and reimport? If the repository has got a bit flakey and things don’t seem to be working correctly, it may be worthwhile. However, if you’ve got no problems with it, it’s probably not worth losing the history you have in the stored revisions.

[quote]I admit, tagging has been a very hard thing for me to understand for whatever reason. I am still learning to ignore the file tags, and only deal with my own “vendor” tags.
[/quote]
(Vendor tags are a great idea, but useless for most people - I guess you’re referring to “repository” tags)

Yeah, it’s a useful ability to tag individual files, but it’s one of those features that becomes more of a pain over time. As projects become larger there’s less and less reasons to tag things on a file level. Just a straight repository tag is what’s usually best.

I’m watching Subversion with interest - we all know CVS is getting a little long in the tooth. The time between releases is becoming measured in years rather than weeks! I hate to throw away a good thing, but there are many constraints in the way CVS works that disallow some really useful things, like renaming or moving files, preserving rwx bits, symlinks etc.

As Subversion gets stable I expect most people will move over to it, in the same way that few people use RCS or SCCS directly anymore. The only thing that really worries me is that you can’t hack the repository by hand… but the rational side of me tells me that Subversion won’t have the same problems as CVS and you won’t need to! ;D

Until then, however, “CVS FOREVER!” :wink: