Forum OpenACS Development: cvs woes
NB: I haven't actually tried this myself, so it's all theoretical at this point...
come to think of it, you wouldn't even need to do a 3-way merge... just re-do the last good vendor import with a new tag, then check out a working copy on the last tag from before the bad vendor import and re-commit it with "cvs ci -r HEAD"... this gets your vendor branch back in shape and brings -HEAD back to where it should be too...
CVS has no "revert" mechanism per se. To back out any change you have to commit the inverse of that change. (Which, in many cases, just means yanking out the immediately previous revision and commiting that again as the latest revision).
But, in your case basically what happened is you did a vendor import of bad stuff? You did the vendor import, then after doing so, realized it was bad, broken, or corrupted in some way? In that case, I think all you need to do is retrieve the last known good vendor import, vendor import that again, and you're fine. The bad import will still be there in your CVS version history, but all its changes will have been reversed.
So say you had good vendor import A, then bad vendor import B. Just pull a clean checkout of the vendor import A out of CVS, exactly as if you were making a release tarball of that vendor code, and then import that again onto the vendor branch as vendor import C.
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?
Well it looks like existing files were modified to me:
tammy@goodchild:tcl] cvs log aa-test-procs.tcl
RCS file: /cvsroot/openacs/packages/acs-automated-testing/tcl/aa-test-procs.tcl,v
Working file: aa-test-procs.tcl
head: 1.1
branch: 1.1.1
locks: strict
access list:
symbolic names:
OACS-4-6-3: 1.1.1.3
release-2003-11-18__branch: 1.1.1.2.0.2
release-2003-11-18__root: 1.1.1.2
upgrade-4-6-1: 1.1.1.2
initial-4-6-1: 1.1.1.2
OACS-4-6-1: 1.1.1.2
current: 1.1.1.1
initial: 1.1.1.1
OACS-initial-install: 1.1.1.1
OpenACS: 1.1.1
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
----------------------------
revision 1.1
date: 2003/03/25 22:58:18; author: nsadmin; state: Exp;
branches: 1.1.1;
Initial revision
----------------------------
revision 1.1.1.3
date: 2003/12/01 21:46:45; author: nsadmin; state: Exp; lines: +38 -1
Upgrade to OpenACS 4.6.3 from openacs.org
----------------------------
revision 1.1.1.2
date: 2003/03/26 00:07:25; author: nsadmin; state: Exp; lines: +1 -1
Upgrade to OpenACS 4.6.1 from openacs.org
----------------------------
revision 1.1.1.1
date: 2003/03/25 22:58:18; author: nsadmin; state: Exp; lines: +0 -0
Initial install OpenACS 4.6 from aufrecht.org
=============================================================================
I still don't understand a few things. Like how come the files got imported to the right place in the directory hierarchy when I imported them the wrong way?! But anyway...
You must have noticed the import problem before you merged any changes from the vendor branch to the Head, right?
yes. I have not merged anything back to head.
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.
No I never modified any acs-automated-testing code at all. So let me understand this, the HEAD got updated to the 4-6-3 import?
But just to be sure I understand all this... What I did imported only the acs-automated-testing package as the tagged branch OACS-4-6-3 (only the testing package gets checked out when I use the -r OACS-4-6-3 option)? Ugh I hate this:(
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.
So do I do it like this?
just re-do the last good vendor import with a new tag
cd /tmp/4-6-1
cvs import -m "Re-doing Upgrade to OpenACS 4.6.1 from openacs.org" openacs OpenACS OACS-4-6-1-cvs-redo
then check out a working copy on the last tag from before the bad vendor import
cd /tmp
cvs -q co -d lastworking -r OACS-4-6-1 openacs
and re-commit it with "cvs ci -r HEAD"... this gets your vendor branch back in shape and brings -HEAD back to where it should be too...
cd /tmp/lastworking
cvs ci -r HEAD
Now can I delete the old, bad OACS-4-6-3 tag and rename the OACS-4-6-1-cvs-redo tag to it's original name OACS-4-6-1?
And now when I cvs checkout -r OACS-4-6-1 it is the original OACS 4.6.1 codebase as expected?
Don't you wish CVS had an atomic "rollback" command? :)
Oh gawd yes. badly.
It's so nice of you guys to help. thanks again and again:)
EEK! That would be awful. At least it sounds awful.
Ok, the following are tags done on vendor imports:
OACS-4-6-3: 1.1.1.1
upgrade-4-6-1: 1.1.1.1
initial-4-6-1: 1.1.1.1
OACS-4-6-1: 1.1.1.1
current: 1.1.1.1
initial: 1.1.1.1
OACS-initial-install: 1.1.1.1
OpenACS: 1.1.1
And these are tags done against (what I hope) are the dev sources:
release-2003-11-18__branch: 1.1.1.1.0.2
release-2003-11-18__root: 1.1.1.1
The reason there are so many tags on my vendor imports is cuz I was following the docs and couldn't decide on a naming convention (yet) so I think I duplicated tags. Like the following are likely all equivalent tags for example:
current: 1.1.1.1
initial: 1.1.1.1
OACS-initial-install: 1.1.1.1
I can still recover from backup if I must. The question is really then though... is there a better way I should have setup my cvs and tagging, etc? Ugh.
simplified, your CVS branching should look something like this
/------ release-2003-11-18 (release)
/
-------------------- trunk (active development)
\
\-------------- vendor branch (imports)
but instead it looks like you have
-------------------- trunk (inactive)
\
\-------------- vendor branch (imports + active development)
\
\------ release-2003-11-18 (release)
The difference between a vendor branch and a regular branch is that CVS updates the trunk behind your back (aka "for you") when you import on a vendor branch.
What I suspect happened when this was first set up is that the original working copy checkout was made with "-r initial" or one of the other early vendor import tags, which would stick the checked out sources on the vendor branch. While everything would look fine, any commits go back onto the vendor branch rather than the trunk. The release-2003-11-18 branch was then made off the checked-out vendor branch rather than off the trunk.
Unfortunately I'm no CVS über-guru, so I have no idea what's the best thing for you to do from here... sorry... I'd probably try something like this, although it may well be more convoluted than nescessary -
- do a fresh import of OACS-4-6-1 onto the vendor branch - the command line you suggested above is fine
- check out a fresh copy of the trunk -
cvs co -d trunk openacs
this should (hopefully) be the same as the 4.6.1 import you just did. If not then make it so and check it in.
- get your local changes -
cvs rdiff -u -r OACS-4-6-1 -D datespec openacs > local-diffs.txt
where datespec is just before the bad import, check the CVS manpage for valid formats
- apply your changes -
cd trunk && patch -p0 < ../local-diffs.txt
- check in your new trunk -
cvs ci
- Bob's your uncle...
Good luck!
First let me say that this really sucks and I just hate it. There I got that out. Funny but I don't feel better. I really appreciate your help on this. I know I wouldn't be thinking about this if I didn't have to!
Here's a cvs stat against a locally modified file in my development working copy
[tammy@goodchild:forms] cvs stat standard.adp
===================================================================
File: standard.adp Status: Up-to-date
Working revision: 1.2 Fri Nov 7 19:27:23 2003
Repository revision: 1.2 /cvsroot/openacs/packages/acs-templating/resources/forms/standard.adp,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
[tammy@goodchild:forms] cvs stat standard.adp
===================================================================
File: standard.adp Status: Up-to-date
Working revision: 1.1.1.1.2.1 Wed Dec 3 02:30:29 2003
Repository revision: 1.1.1.1.2.1 /cvsroot/openacs/packages/acs-templating/resources/forms/standard.adp,v
Sticky Tag: release-2003-11-18__branch (branch: 1.1.1.1.2)
Sticky Date: (none)
Sticky Options: -kk
So maybe I have this?
-------------------- trunk (active development)
\
\-------------- vendor branch (imports)
\
\------ release-2003-11-18 (release)
cd $OACS_DEV_ROOT
cvs tag release-2003-11-18__root
cvs tag -r release-2003-11-18__root -b release-2003-11-18__branch
cd $OACS_TEST_ROOT
cd ..
cvs -q checkout -P -kk -r release-2003-11-18__branch -d or-test openacs
much thanks and metta:)
I have a vague feeling I may be making more complexity than is nescessary here... It might be worth grabbing a copy of CvsGraph (or WinCVS if you're that way inclined) to see what's actually going on rather than poking around and listening to me speculate...
As for documentation I haven't read Fogel, but I have found the Cederqvist to be very useful in understanding CVS concepts.
$ 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
which you posted earlier above, right? If that's the case, then your
only problem is you have some files where they don't belong. So I'm
going to assume here that that's the only problem. (If you have
reason to suspect other problems with your CVS repository, explain
what and why, of course.)
Ok, in your
/tmp/oacs-4-6-3/packages/acs-automated-testing/ directory
that you used for the import, there are exactly 4 files, no more no
less:
So when you did your import above, instead of telling it to import the files into "openacs/packages/acs-automated-testing", you messed up and told it to import the files into "openacs", which means the root directory of your "openacs" CSV project.$ ls -F acs-automated-testing.info sql/ tcl/ www/
Where's your CVS repository, "/cvsroot"? Let's assume that's where it is. So look in your CVS repository, I bet you'll find a "/cvsroot/openacs/acs-automated-testing.info", which doesn't belong there. You need to get rid of that, as it's supposed to be at "/cvsroot/openacs/packages/acs-automated-testing/acs-automated-testing.info".
Basically, your cvs import slammed the "acs-automated-testing" directory and everything beneath it (its tcl, www, and sql directories, etc.) to directories up (../../) from where the stuff was supposed to go.
So, first find out if the scenario I painted above matches what you actually did and what actually happened. Next, I think you may have done some other stuff too that you didn't tell us about.
For example, above you posted some CVS log output which says that for
/cvsroot/openacs/packages/acs-automated-testing/tcl/aa-test-procs.tcl,v
you vendor imported 3 version, most recently on Dec. 1 with a comment
of "Upgrade to OpenACS 4.6.3 from openacs.org", and since you never
committed any of your own changes on that head, that latest vendor
import is the live revision on the Head too.
Looks like you successful imported the 4.6.3 version of that file just like you wanted to. But, unless I'm completely missing something here, the cvs import command you said you used could not have been responsible for correctly importing that file. It couldn't, because you told it to import it into a different directory. Did you do two cvs imports? One wrong and then another that you got right? If so that would explain it.
Yes.
And the exact command you used was 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
which you posted earlier above, right? If that's the case, then your only problem is you have some files where they don't belong. So I'm going to assume here that that's the only problem. (If you have reason to suspect other problems with your CVS repository, explain what and why, of course.)
Absolutely right. I pulled that command right out of my saved shell history. And yes I have believed everything else with cvs was working up to that point.
Ok, in your /tmp/oacs-4-6-3/packages/acs-automated-testing/ directory that you used for the import, there are exactly 4 files, no more no less:
Yes again exactly as you showed above.
Where's your CVS repository, "/cvsroot"? Let's assume that's where it is. So look in your CVS repository, I bet you'll find a "/cvsroot/openacs/acs-automated-testing.info", which doesn't belong there. You need to get rid of that, as it's supposed to be at "/cvsroot/openacs/packages/acs-automated-testing/acs-automated-testing.info".
Now this is what I would have thought too (after doing the import the wrong way that I did). But in fact, no. There is no file "/cvsroot/openacs/packages/acs-automated-testing/acs-automated-testing.info". I don't understand why either:(
Ok wait, now I pulled this out of my shell history (I am using Terminal on OS X and I saved the output of the whole mess as a text file). I just noticed that the output of the import shows the files going to the "right" place though the command is "wrong."
bash-2.05a$ cvs import -m "Upgrade to OpenACS 4.6.3 from openacs.org" openacs OpenACS OACS-4-6-3
cvs import: Importing /cvsroot/openacs/packages
cvs import: Importing /cvsroot/openacs/packages/acs-automated-testing
cvs import: Importing /cvsroot/openacs/packages/acs-automated-testing/sql
cvs import: Importing /cvsroot/openacs/packages/acs-automated-testing/sql/oracle
U openacs/packages/acs-automated-testing/sql/oracle/acs-automated-testing-create.sql
U openacs/packages/acs-automated-testing/sql/oracle/acs-automated-testing-drop.sql
cvs import: Importing /cvsroot/openacs/packages/acs-automated-testing/sql/postgresql
U openacs/packages/acs-automated-testing/sql/postgresql/acs-automated-testing-create.sql
U openacs/packages/acs-automated-testing/sql/postgresql/acs-automated-testing-drop.sql
cvs import: Importing /cvsroot/openacs/packages/acs-automated-testing/tcl
U openacs/packages/acs-automated-testing/tcl/aa-test-procs-oracle.xql
U openacs/packages/acs-automated-testing/tcl/aa-test-procs-postgresql.xql
U openacs/packages/acs-automated-testing/tcl/aa-test-procs.tcl
U openacs/packages/acs-automated-testing/tcl/example-procs.tcl
U openacs/packages/acs-automated-testing/tcl/example-test-procs.tcl
U openacs/packages/acs-automated-testing/tcl/filter-procs.tcl
cvs import: Importing /cvsroot/openacs/packages/acs-automated-testing/www
U openacs/packages/acs-automated-testing/www/index.html
cvs import: Importing /cvsroot/openacs/packages/acs-automated-testing/www/admin
U openacs/packages/acs-automated-testing/www/admin/clear.tcl
U openacs/packages/acs-automated-testing/www/admin/component.adp
U openacs/packages/acs-automated-testing/www/admin/component.tcl
U openacs/packages/acs-automated-testing/www/admin/index-oracle.xql
U openacs/packages/acs-automated-testing/www/admin/index-postgresql.xql
U openacs/packages/acs-automated-testing/www/admin/index.adp
U openacs/packages/acs-automated-testing/www/admin/index.tcl
U openacs/packages/acs-automated-testing/www/admin/master.adp
U openacs/packages/acs-automated-testing/www/admin/rerun.tcl
U openacs/packages/acs-automated-testing/www/admin/testcase-oracle.xql
U openacs/packages/acs-automated-testing/www/admin/testcase-postgresql.xql
U openacs/packages/acs-automated-testing/www/admin/testcase.adp
U openacs/packages/acs-automated-testing/www/admin/testcase.tcl
No conflicts created by this import
Huh?
Next, I think you may have done some other stuff too that you didn't tell us about. For example, above you posted some CVS log output which says that for /cvsroot/openacs/packages/acs-automated-testing/tcl/aa-test-procs.tcl,v you vendor imported 3 version, most recently on Dec. 1 with a comment of "Upgrade to OpenACS 4.6.3 from openacs.org", and since you never committed any of your own changes on that head, that latest vendor import is the live revision on the Head too.
No I didn't do anything else. There should be 3 vendor imports of acs-automated-testing because I originally imported OACS 4.6 from Joel's site. Then later updated to 4.6.1 via import. And just on Dec 1st tried to import ONLY the acs-automated-testing package but that is the import that got screwed up and its tagged OACS-4-6-3. And yes I never did any changes to the testing package of my own, in fact I had never used it until a few days before Dec 1st.
Looks like you successful imported the 4.6.3 version of that file just like you wanted to. But, unless I'm completely missing something here, the cvs import command you said you used could not have been responsible for correctly importing that file. It couldn't, because you told it to import it into a different directory. Did you do two cvs imports? One wrong and then another that you got right? If so that would explain it.
That exactly the problem I'm having understanding this. I did the one import and it was wrong! I have my shell output saved and there is only one import command in it and it's clearly wrong. But the files do not exist 2 dirs up in my cvsroot as I would have expected them to. And it does look like they got imported into the right place. How I don't know! And if I did one wrong import and one right later (who knows anymore though I don't see it in my shell logs), wouldn't the wrong import still have the files in the cvsroot 2 dirs up??? Argh.
So maybe somehow my import is ok? This is weird and not comforting but would be nice to get this resolved and be able to confidently use cvs again.
Yet if I check out via the OACS-4-6-3 tag, I will get only acs-automated-testing package. And it looks like from my stats of files in acs-automated-testing that already the 4-6-3 files are at the HEAD of my working/dev copy. Maybe nothing is wrong but choice of tag name is poor?
This has been one wild ride. I am going to look at cvsgraph just to make myself feel like I have a bit more confidence that things are ok.
Tammy, you did not "branch from a branch", at least not in any bad way as you may fear. It is possible to branch from a branch in CVS, but I've never yet had a reason to do it, and anyway, I don't think you need to worry about that. You said you did this:
It's been a long time since I did much branching, but taking a quick look at my CVS notes, that looks just fine to me.$ cd $OACS_DEV_ROOT $ cvs tag release-2003-11-18__root $ cvs tag -r release-2003-11-18__root -b release-2003-11-18__branch
Note that your "cvs stat standard.adp" command showed that that your "release-2003-11-18__branch" tag is on rev. "1.1.1.1.2" of that file. All those digits in the rev. number might seem confusing, but it's normal, I've seen that before. All it means is that you never committed any modification to that particular file before you branched.
Technically, maybe that's "branching from the vendor branch", and way the revision numbers are constructed suggest that's really the way CVS looks at it underneath. But for that file at that point in time, the vendor branch and the Head are one and the same, just different names for the same thing. Basically, that file is currently sitting right where the two branches (the Head and the vendor branch) join. Edit that file and commit on the Head, and you'll see all future branches starting from rev. 1.3 or whatever rather than 1.1.1 like they do now. Nothing to worry about there.
Incidentally, "openacs" is a pretty confusing and thus bad name to pick for your own custom CVS project. There's a reason you see examples using "mysite" or whatever instead... Much clearer to pick some name suggestive of your project, "big-client-inc", "subverge-fork", "tammy-loves-openacs", whatever.
Yeah I agree my choice of names for my cvs project is not so good. I did this from some sample docs when I was just toying with the idea of using OACS and then of course, it became a reality and it never got changed. It is annoying and not informative. But I don't have the courage to try and rename my cvs project after this fiasco! ;(
And I'm really glad it sounds like the consensus is that my vendor and release branches are ok. I read a lot of Fogel last night and I was thinking they might be too. Yay.
Thanks a ton for all the help and patience guys. And Russell, no worries, you got me thinking and made me brush up on my cvs which I clearly needed to. And I am also quite good at making things much more complicated than they need to be. I appreciated the companionship on my latest venture down that path;)
"release-2003-11-18__branch" was branched off tammy's main development tree, but the revision numbers there look very much like it was branched from the vendor branch rather than from the trunk (all the CVS documentation I've ever seen says that all revision numbers on the trunk have a single period and gain 2 periods for each branching away from the trunk). 1.1.1 is the default vendor branch, so it would be normal for a file unchanged since import to be on the trunk with revision "1.1.1.1" as you say, but "1.1.1.1.2.1" is a revision on a branch off the vendor branch. If "release-2003-11-18__branch" was branched off the trunk then the revision numbers there would be of the form "1.x.2.y"
If this is the case then the development tree *is* the vendor branch and fixing it isn't as simple as just redoing the import... This situation isn't hard to imagine - if the original working copy was checked out with the release tag of the initial import (an easy mistake to make) then that working copy will be on the vendor branch. Since this was the first import since the initial one everything would have appeared to be working fine in the interim.
Like I said it looks to me like development may be on the wrong branch, which would cause problems with imports, but I'd want to see output from something like CvsGraph before speculating any further. I'll shut up now...
CVS is really only a per-file version control system, remember. The revision number on the file is not necessarily in sync in any fashion whatsoever with the revision numbers of any other files. The tag is the only thing that groups all those branch revisions of individual files together into one big thing we think of as "the branch".
or the last, I suspect.
tammy - never mind me, I'm a moron. please ignore pretty much everything I've said here...
Having your tag named "OACS-4-6-3" only on the acs-automated-testing package is pretty confusing. You tagged the right thing, you just picked a confusing name for the tag. So I would put a new tag on the same spot, named "acs-automated-testing-oacs-4-6-3" or something like that, then remove the old "OACS-4-6-3". (That way when you later want to actually import all of OpenACS 4.6.3 you won't be confused about why you already have an "OACS-4-6-3" tag, etc.)
Ok so one last lame question then... is the following true? When I import on my vendor branch (correctly!), the imported files just become head of the trunk if no changes were ever made to them? And if changes were made, when I update or commit in my working copy, I will find out and have to merge then? There is no separate merge needed like when a branch is created and work done there, you have to merge back the changes to the trunk to see them in the working copy (after update|checkout)? So importing is effectively applying the files imported to my trunk head.
And I used cvsgraph on a few files and it looks weird. Maybe I'm not reading it right but it looks like my "release branch" branched off the vendor import branch for files in OACS base code but for a file that is new and doesn't exist in OACS base code, it looks like it branched off the main branch (as desired and expected)! Anyone wanna take a look and tell me if I am misinterpreting the cvsgraph?
I was feeling good about the release branch commands having worked right too... ugh. Wait a minute, I checked out using the release tag and it got me what I expected: latest OACS base (latest I had imported, before the 4-6-3 import disaster) plus my own additions. How could it be branching off the vendor branch then?
Actually looking closer at the cvsgraph of the new file (added by me, not in OACS base), it looks like the release is tagged correctly. The root_of_release tag is on the trunk and the __branch tag is branching off the trunk at that point. Of course on the other file (existing in OACS codebase) maybe it makes sense the root_of_release tag appears to be on the vendor branch for this file. It is where the file was first imported, thus it's first version lives there. me thinks...
I think cvsgraph display is just more confusion on my overtaxed mind this morning. Ugh. I have to stop thinking about this... that is the solution!!!
Anyway if ya wanna look at cvsgraphs of my tree the links are above. Back to coding today. Thanks so much for all the help:)
Also, I've never used cvsgraph nor gone over how CVS treats branch revision numbers with a fine toothed come, but what you're describing there sounds normal to me, Tammy.
Ugh. I have to stop thinking about this... that is the solution!!!
:) It is rather ironic that in this case, had you been completely clueless and just ignored everything, you'd never have noticed the mistake in your cvs import command, you never would have suspected any problems at all, and everything, coincidentally, would have been fine!
:) It is rather ironic that in this case, had you been completely clueless and just ignored everything, ... everything would have been fine!
Doh!
That didn't escape me, Andrew. Thanks for bringing it up! I just felt my stomache sink as I realized the import command was wrong after I hit return and watched the output whiz by. Shoulda read it more clearly and not totally panicked, aye? Thanks for setting my head straight again, feels much better that way:)
That's not quite how CVS handles vendor imports. If a file on the trunk has no local modifications then yes, it is replaced with the one from the import and that change will show up in your working copy the next time you update. However, files with local modifications aren't automatically merged by CVS or anything like that. The import command tells you that you need to do a merge, and shows you how -
1 conflicts created by this import.
Use the following command to help the merge:
cvs checkout -jvendor:yesterday -jvendor module
The branching you see is actually correct - since standard.adp hasn't had any changes made to it, the tip of the trunk, the tip of the vendor branch and the tip of the release branch are all the same file and CVS seems to want to show the "most branched" interpretation. If you commit a change to that file on the release branch then it should collapse back to being branched off the trunk as Andrew described in the 00:15:21 post...
