Forum OpenACS Development: Re: cvs woes
Thanks everyone for giving me some options to consider here.
Andrew, I can give you the sad details of what happened yesterday. It all started off innocently enough...
I was trying to start using acs-automated-testing. I wrote a sample test case but then realized I needed the 4.6.3 version of the package where aa_run_with_teardown had been added. I thought I would just import only this package since it didn't seem to have many changes I thought would stop it from working with my 4.6.1 base import of OACS. Except maybe timestamp -> timestampz.
So I did this :
cd /tmp/oacs-4-6-3/packages/acs-automated-testing
cvs import -m "Upgrade to OpenACS 4.6.3 from openacs.org" openacs OpenACS OACS-4-6-3
Maybe I haven't trashed my original vendor import... but
I think this imported just this single package over top of my entire OACS code base. If I run a diff of the 2 tags I see this:
cvs -q diff -r OACS-4-6-3 -r upgrade-4-6-1
cvs diff: tag OACS-4-6-3 is not in file 4-6-1/license.txt
cvs diff: tag OACS-4-6-3 is not in file 4-6-1/readme.txt
cvs diff: tag OACS-4-6-3 is not in file 4-6-1/bin/acs-4-0-publish.sh
cvs diff: tag OACS-4-6-3 is not in file 4-6-1/bin/ad-context-server.pl
cvs diff: tag OACS-4-6-3 is not in file 4-6-1/bin/create-sql-drop-file.pl
cvs diff: tag OACS-4-6-3 is not in file 4-6-1/bin/data-dictionary-diff.pl
...
Index: 4-6-3/packages/acs-automated-testing/www/admin/rerun.tcl
===================================================================
RCS file: /cvsroot/openacs/packages/acs-automated-testing/www/admin/rerun.tcl,v
retrieving revision 1.1.1.3
retrieving revision 1.1.1.2
diff -r1.1.1.3 -r1.1.1.2
2c2
< @cvs-id $Id: rerun.tcl,v 1.1.1.3 2003/12/01 21:46:45 nsadmin Exp $
---
> @cvs-id rerun.tcl,v 1.2 2002/09/10 22:22:04 jeffd Exp
...
It looks like only the acs-automated-testing package was imported and tagged OACS-4-6-3. Maybe the base import is fine? I guess what I need to figure out is what is the "right" way to import an upgrade to vendor code of only a single package and then merge it into my vendor main branch. And of course, to verify I can still checkout an intact vendor branch and a main trunk with my local changes.
If the base import is not fine, I suppose I could recover the day before's cvsroot from amanda tape backups. Though we'd have to re-commit all changes from that day forward. Which may be easier than dealing with a cvs fix of this. Though I apparently could do with some refreshing on cvs use and a bit of practice couldn't hurt (figuratively speaking).
Have I confused everyone else as bad as myself yet, because I could go on?!!!
$ cd /tmp/oacs-4-6-3/packages/acs-automated-testing
$ cvs import -m "Importing OpenACS 4.6.3 Automated Testing package." openacs/packages/acs-automated-testing openacs acs-automated-testing-OACS-4-6-3
Ugh. It's an easy mistake to make. This is one very good reason to
always backup your CVS repository before doing any complicated import
operations which you're unsure about, or to test them first on a
testing copy of your real repository. Since you don't have a backup
to revert to, you've got to fix it instead.
There isn't really any such thing as "trashing your original vendor import", as that's not possible using just cvs import commands. But what you've done is pollute your repository with additional files that should never have gone there in the first place, which, while not as bad as any real "trashing", may feel like a pretty close approximation!
If all the import did was add brand new files which never existed before, then the fix is pretty simple, just go into your cvs repository (back it up first!), and manually (carefully!) delete the bogus "*,v" files. Presto, it's now as if the bogus import never happened.
However, if good files with the same names may have already existed, then you need to be more careful. Probably the easiest way to check this is to use cvs log on each of the bogus bad files you just imported. From the cvs log output, you should be able to tell if your mis-placed vendor import touched files that were already there before, or just created brand new files where none existed before.
If your bogus import did touch previously existing files, my guess is you should use cvs import again to put the old file back, as mentioned above. You must have noticed the import problem before you merged any changes from the vendor branch to the Head, right? If so, then keep in mind here, that this problem, if it is present, probably only exists because if you have not ever modified those old good files on the Head from when you first vendor imported them, when you vendor import a "new" version (in this case, your bogus misplaced import) CVS helpfully immediately updates the file on the Head as well because since it was never modifed, the Head and the vendor branch are still the same thing at that point for that file.
Don't you wish CVS had an atomic "rollback" command? :) Heh Roberto, does Arch have that?
