OpenCVS mini hackathon

It's Sunday, nice weather outside and I'm sitting on my couch typing up this stuff while Tobias is trying to figure out how to get back home after an entire weekend of nothing but OpenCVS hacking.

I thought it would be nice to write a background story on the mini hackathon and any major changes. All stories start at point A, so lets do the same!

After shredding my 2nd World of Warcraft CD set, I decided I was going to need something productive to keep myself from relapsing, again.

So I set my focus on OpenCVS again and found that both Tobias and Xavier were still actively writing some code for it. I was pleasantly surprised although a bit nervous about coming back to something I left behind to go play with elves and big cows. They both didn't make an issue out of it and OK'd some old diffs I had sitting in my mailbox and tree.

After a few days of hacking, things were going slowly and we started looking at our goals again. One of those goals is to be able to replace GNU cvs with OpenCVS for the OpenBSD anoncvs mirrors. We quickly figured out what we lack to be able to present anoncvs mirrors with real functionality instead of the basic checkout/update/diff.

The biggest show stoppers were:
• -D (date) support for some commands
  
• the -d argument for checkout
  
• rdiff / rannotate
  
• CVSROOT/modules
  
• -j for checkout and update
  
• proper path validation in client<>server communication
  

While Tobias and Xavier were making sure OpenCVS is as conforming to GNU cvs as possible when it came to output, I started hacking on CVSROOT/modules.

After a few hours, I had something basic working and it got committed. Within days, with help from Tobias and Xavier, we pushed up most of the stuff that it needed to do. We were sastisfied when OpenCVS could properly handle all cases in OpenBSD's own CVSROOT/modules (of course it can handle all options)

With all the stuff that was going on, I joked to Tobias he should drive over to my place and we should have an OpenCVS hack weekend. To my surprise he agreed and we set a date: Feb 8th until Feb 10th.

On Friday, only 5 hours late, Tobias arrived at my place and we immediately set ourselves up for hacking. We discussed about how to approach certain issues and decided to tackle -D as a first goal.

The same night we committed basic -D support, which allowed OpenCVS to actually do:

opencvs -d /cvs co -D "10 years ago" src

On Saturday, we continued -D support by allowing OpenCVS to actually use the CVS/Tag and CVS/Entries file in combination with it. Unfortunately, this proved to be more difficult then we first imagined due to the way our current code was written (only for symbolic tags, not dates).

Our entire Saturday was spent fixing code that needed to be modified in order to work with both dates and symbolic tags, while maintaining readable, non-sucky, workable code. CVS is complex and has tons of buttons, which is definitely not a good thing.

Sunday morning looked bright as all our -D stuff was working and we were happy. We tackled a major hold back on OpenCVS and went on to another step we deemed highly needed: proper path validation.

Tobias had some great ideas on how to do this, so we started it. We wrote some initial code that has been committed but alas a weekend only lasts 2 days and since it was Sunday, Tobias had to drive home in the afternoon.

So all in all, this weekend has been mostly about -D even though we both wanted more, including -j. But I'm sure we can get that in soon.

For the curious, here's a list of commits that went in this weekend:

• do not override the specified tag (-r on the command line) with a directory tag (if present) since this breaks certain things
• do not override a specified (-r) tag with the tag in the Entries file
• when checking if a file is really dead, do not use cvs_specified_tag only. instead use the local variable 'tag' which is filled in by our code to match the correct tag (specified on the command line, or in Entries)
• get in initial support for checkout -D. Works fine with -r support right now
• lets do -D for update as well
• get in proper support for checkout/update -A when it comes to keyword expansion options
• if run as server, (r)diff should properly write (r)diff into header instead of "server"
• make sure the client creates the correct CVS/Repository when running checkout if there was no -d targetdir specified
• allow -D to work remotely for both checkout and update
• always remove the additional .0 from magic branches, even when running the log command and change getlog.c so it will add any .0 magic branches in its output. Less confusing for rcs_translate_tag()
• get date support into annotate, too
• if the CVS/ directory already exists when we reach cvs_mkadmin() we will definitely need to recreate it with the correct information. Otherwise successive checkouts of the same module with other arguments like -r or -D will not store the correct information
• support for checkout -D extended: properly write CVS/Tag and CVS/Entries on various combinations of -r and -D
• in cvs_update_enterdir() write the CVS/Tag file if the cvs_specified_date is != 0 as well
• introduce cvs_ent_line_str() - formats CVS/Entries lines
• parse any date tags set in CVS/Tag or CVS/Entries properly, and use them for commands
• properly initialize cvs_specified_date so we don't end up with random stuff going on
• regression: re-enable client<->server remote setup. Use -DREMOTE.
• cvs_write_tagfile() is not responsible for removing CVS/Tag itself construct right CVS/Repository paths in cvs_mkpath()
• properly handle dates in a remote setup if we send / receive them
• respond with "Updated" instead of "Checked-in" on server-side if a client committed files so keywords are expanded properly on client-side, we have to be careful about the directory ./ when it comes to commits, so add a test for CVS_OP_COMMIT
• do not allow commits to files that have a sticky date set
• status: add support for sticky date
• introduce cvs_validate_directory(), which is used to check directory path to make sure they do not fall outside the CVSROOT or the working copy directory in a remote setup

Thanks for the fun weekend and the German beer, Tobias!

And as always, if you want to help us out - TEST OpenCVS and do not wait until it gets linked to the build to run it. If you want it linked and used, TEST TEST TEST it.