Checkpoint my cvs interface to the workbench. This first cut uses the
"rtag" directive to initiate template modify operations. So, to get started you do a checkout: cvs -d ops.emulab.net:/proj/$pid/templates/XXXXX/cvsrepo checkout XXXXX where XXXXX is the part of the guid (10000/1) before the slash. Might try and roll all templates into a single project wide repo at some point, to avoid the extraneous path stuff, but didn't want to worry that just yet. Okay, so have a checkout. You can work along the trunk, doing commits. To create a new template (a modify of the existing template), you tag the tree using rtag: cvs -d ops.emulab.net:/proj/$pid/templates/XXXXX/cvsrepo rtag mytag XXXXX A template modify is started at the end, and you should probably wait for email before continuing. Eventually I will need to add locking of some kind, but I have to do the modify in the background, or else I get deadlock cause cvs keeps the repo locked, and the modify also needs to access it. Each time you tag along the trunk, you get a modified template, which in the history diagram looks like: 10000/1 --> 10000/2 --> 10000/3 ... If you want to branch, say at 10000/2 you can create a branch tag using rtag: cvs -d [cut] rtag -r T10000/2 -b mytag2 XXXXX You can also use your own tags for -r option, but I also create a TXXXXX/YY tag at each template modify, which is easy to remember. Then update your sandbox to the new branch, commit changes along that branch, and then later use rtag again to initiate a template modify operation: cvs update -r mytag2 cvs commit ... cvs -d [cut] rtag -r mytag2 mytag3 XXXXX And now the history diagram looks like: 10000/1 --> 10000/2 --> 10000/3 ... | | -> 10000/4 ... You should be able to mix interaction via the web with interaction via the cvs interface. I've tested it, although not extensively.