Home
The Toolkit for Online Communities
16677 Community Members, 1 member online, 2535 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : cvs woes

Forum OpenACS Development: cvs woes

Icon of envelope Request notifications

Collapse
Posted by tammy m on
Is there a way to permanently revert a "cvs import" on an existing vendor branch without, of course, affecting the state of the vendor branch prior to the last/bad import? this is not a fun question to ask;(
Collapse
2: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
ouch! I'd try this on a copy of your cvsroot first, but you may be able to get away with doing another import of the last non-broken vendor sources, and then in your working copy doing a 3-way merge between the last good version and the new good version into your current -HEAD (which should be a null diff, but bring cvs's idea of -HEAD back to the right spot)... This would leave a record of the botched import in your repository, but should get your current development sources back on track....

NB: I haven't actually tried this myself, so it's all theoretical at this point...

Collapse
3: Re: cvs woes (response to 2)
Posted by Joel Aufrecht on
You might also try exporting from cvs with a date-stamp from just before the bad import, which will get you a file tree with good files.  Then import that back in to cvs.  Brute force and maybe confuses the logs a bit, but easier to understand than three-way merges.
Collapse
4: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
but the point of vendor branches is to let you easily track local changes relative to a changing external source tree... if you just fix -HEAD without also fixing the tip of the vendor branch then when it comes time to do the *next* import cvs will consider your "local changes" to be the diff from the botched import to the current source tree rather than from the last good import to the current tree, leading to more pain down the track...

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...

Collapse
5: Re: cvs woes (response to 1)
Posted by Andrew Piskorski on
Tammy, can you give a more detailed, concrete example of what CVS snafu you've run into and how? That should help us give better advice.

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.

Collapse
6: Re: cvs woes (response to 1)
Posted by tammy m on
Hi

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?!!!

Collapse
7: Re: cvs woes (response to 6)
Posted by Andrew Piskorski on
Tammy, yes, you imported your new acs-automated-testing package into the wrong place - you left out a parameter to your cvs import command. In your case, you should have done (see also the import examples in my CVS doc):
$ 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?

Collapse
8: Re: cvs woes (response to 1)
Posted by tammy m on
Hi again,

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
=============================================================================
Too bad, I really preferred the "delete by hand, presto like it never happened" version of the recovery process;(

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:)

Collapse
9: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
OK... From the look of the revision numbers against the tags in that "cvs log" output I think you may be running your development sources off the vendor branch itself rather than off the CVS trunk... I'm assuming that "OACS-initial-install", "OACS-4-6-1" and "OACS-4-6-3" are tags specified when you've done imports, and that the rest of them are tags you've applied to your development sources? (revision numbers on the trunk have a single dot, and every branch you are away from the trunk gets another 2 dots in the revision number - diagram here). If this is the case then what I said before about fixing it up won't (I think) work since the vendor branch and your development head are the same thing. Perhaps it'd be easier to just recover from backup...
Collapse
10: Re: cvs woes (response to 9)
Posted by tammy m on
Russell,

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.

Collapse
11: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
Ah, so if you do a "cvs stat" against a locally modified file in your development working copy it has a revision number like "1.1.1.x" and anything modified on the release-2003-11-18 branch is like "1.1.1.x.2.y"?

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...
  • that should (I hope) get your trunk and OpenACS vendor branch back in shape. If the release-2003-11-18 branch doesn't have any local changes on it I'd be tempted to abandon it and re-branch from the trunk for releases...

    Good luck!

Collapse
12: Re: cvs woes (response to 11)
Posted by tammy m on
Hi again Russell,

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)
and a cvs stat of a file modified on the release-2003-11-18 branch
[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 it looks like maybe I am working off the trunk but my release branch somehow got made off the vendor branch?

So maybe I have this?

-------------------- trunk (active development)
    \
     \-------------- vendor branch (imports)
              \
               \------ release-2003-11-18 (release)
This is how I created the release branch though...
	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

Have to think about what to do now. Reading more on branches and numbering so I can understand what is really going on here versus what should be going on here... :( Fogel makes nice bedtime reading...

much thanks and metta:)

Collapse
13: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
hmmm... that's not what I expected... :(

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.

Collapse
14: Re: cvs woes (response to 1)
Posted by Andrew Piskorski on
Whoa, I didn't look carefully at all those diagrams and stuff above, but I think the two of you are going off down some blind alleys here. Tammy, the only thing wrong as far as you know is you gave the wrong cvs vendor import command above, right? 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.)

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:

$ ls -F
acs-automated-testing.info  sql/  tcl/  www/
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.

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.

Collapse
20: Re: cvs woes (response to 14)
Posted by tammy m on
Tammy, the only thing wrong as far as you know is you gave the wrong cvs vendor import command above, right?

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.

Collapse
16: Re: cvs woes (response to 1)
Posted by Andrew Piskorski on
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.

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:

$ 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
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.

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.

Collapse
21: Re: cvs woes (response to 16)
Posted by tammy m on
Hi again,

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;)

Collapse
15: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
Andrew - it wouldn't be the first time I've made something more complicated than it needs to be, but here's why I think there may be more going on than just a botched import -

"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...

Collapse
18: Re: cvs woes (response to 15)
Posted by Andrew Piskorski on
Hm, let's see. Branch revision 1.1.1.1.2 is definitely ok, you get that by doing one vendor import (rev. 1.1.1.1), changing nothing on the head (still 1.1.1.1), then branching (1.1.1.2). (I have a known good example in front of me that shows the exact same thing). And rev. 1.1.1.1.2.1 would then be the first revision on that branch. And this is supposed to be the branch for "release-2003-11-18", so... It's fine. I'm reasonably sure anyway. Looks like Tammy branched for a release, then fixed a bug on the branch; entirely normal.

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".

Collapse
17: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
it wouldn't be the first time I've made something more complicated than it needs to be

or the last, I suspect.

tammy - never mind me, I'm a moron. please ignore pretty much everything I've said here...

Collapse
19: Re: cvs woes (response to 17)
Posted by Andrew Piskorski on
Oh, I guess you already noticed the same stuff as me. :)
Collapse
23: Re: cvs woes (response to 1)
Posted by Andrew Piskorski on
Looks like your original "bad" cvs import somehow did what you wanted, rather than what you told it to do, and everything is fine. I tried a similar cvs import yesterday and it put the files in the wrong place just we both expected. But somehow, yours worked fine. Why, I've no idea, but sounds like some additional CVS magic going on behind the scenes there.

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.)

Collapse
22: Re: cvs woes (response to 1)
Posted by tammy m on
I'm going to assume nothing is wrong with my "bad" import other than the tag is named deceptively and I can't checkout a full OACS-4-6-3 on it as the name implies. And I'll rename the tag as Andrew suggests.

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:)

Collapse
24: Re: cvs woes (response to 22)
Posted by Andrew Piskorski on
Yes, the special behavior of vendor branches is as you decribe. I never really dug into why or how CVS does implements that, but that's the behavior I remember always seeing.

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!

Collapse
26: Re: cvs woes (response to 24)
Posted by tammy m on

:) 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:)

Collapse
25: Re: cvs woes (response to 1)
Posted by russell muetzelfeldt on
trying to salvage some credibility here.. :)

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 -jvendormodule
so when you do this checkout CVS does the merge (and you manually resolve any conflicts) - it's the same process as merging changes from any other branch back to the trunk. There is no indication when you update your existing working copy that you need to do this, just the output from the import.

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...