1. 09 Jul, 2007 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint my cvs interface to the workbench. This first cut uses the · 8371fc79
      Leigh B. Stoller authored
      "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
        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.
  2. 28 May, 2007 1 commit
    • Leigh B. Stoller's avatar
      Implement two requests by Eric: · e12ea1e2
      Leigh B. Stoller authored
      * The checkout directory now includes just the datastore directory and
        tbdata/nsfile.ns. This removes a bunch of clutter.
      * You can now run template_commit in any subdir of a checkout; the
        python wrapper will crawl upwards looking for the .template file.
        Note that I removed the option that allowed you to do a commit from
        the template tree in /proj/pid/templates since that directory will
        ultimately go away (or at least hide from view), and cause it
        conflicted with the new option and I didn't want to make things any
        messier for no reason.
  3. 23 May, 2007 1 commit
    • Leigh B. Stoller's avatar
      First cut at template checkout and commit from a checkout. The interface · b674bc7b
      Leigh B. Stoller authored
      described is the one exported to ops via the XMLRPC interface. This is
      just playing aroundl no doubt this stuff is going to change.
      * template_checkout guid/vers
        Checkout a copy of the template to the current working directory.
      * template_commit
        Modify the previous template checkout, using the nsfile contained in
        the tbdata directory (subdir of the current directory). In other words,
        the current template is modified, creating a new template in the
        current working directory (the current directory refers to the new
        The datastore subdir is imported into the new template, but that is
        the only directory that is imported at present. Might change that.
      So this sounds much cooler then it really is. Why?
      * This only works from ops.
      * The "current directory" must be one of the standard approved directories
        (/proj, /users, /groups).
      * Cause, boss reads and writes that directory via NFS, as told to it
        by the xmlrpc client.
      At some point in the future it would be nice to support something
      fancier, using a custom transport, but lets see how this goes.