Forum OpenACS Q&A: CVS Help
I'm trying to upgrade a site (from 4.6.1 to 4.6.2, on the way to 4.6.3) following the instructions in the administrator guide. I have my site in a CVS repository so I've gone through the steps of unpacking the tarball and importing it. But when I look for conflicts I see that any file that was not part of the tarball is "scheduled for removal" and aren't in the temporary checkout.
What I don't know enough about CVS to know is: if I reconcile any conflicts and commit those changes (step 3), are all those "scheduled for removal" files (i.e., all my work) going to be deleted when I update by working CVS directory (step 4)? It sure looks that way.
So, am I doing something wrong or is there another way to do this upgrade if your CVS has a lot of extra custom work that isn't part of the distribution?
Just to expand a little bit -- I guess the OACS CVS is set up so that every package is in a separate CVS module. I don't quite see how that's been done since /packages is part of acs-core but /packages/forums, for instance, isn't. When you update acs-core, doesn't it always ask you to add /packages/forums and all the other packages that aren't part of acs-core?
Anyway, maybe my problem is that my CVS tree is a single monolithic module, containing the core, all the distributed packages and all my packages lumped in together, which makes it hard to just upgrade acs-core? If so, how would I go about reconfiguring my CVS tree so that it matched the OACS CVS organization, and so that I could upgrade a little less painfully?
No, there's nothing wrong with the directory structure of your CVS tree, yours is the same as the OpenACS CVS repository. The CVS "modules" thing is a different feature, it doesn't matter here.
Andrew, I've been looking at your CVS conventions page but I have to admit I'm still lost. I think it's the vendor tag thing that I've never understood, or enough about branching and mergin changes between branches.
My site started with a 4.5 beta and wasn't created in accordance with current procedures. What happens is that when I do cvs checkout -d openacs-upgrade -jOpenACS:yesterday -jOpenACS openacs (or similar, see below), packages that I've written aren't of course in the distribution so I guess it looks like they have been removed from the distribution.
I think this is where the vendor tag comes in. The OpenACS in -jOpenACS, is that a vendor tag? I didn't actually use those tags because they didn't make any sense in my cvs -- instead I did a cvs rtag pre_4-6_2_upgrade before starting, then cvs import -m "upgrade to OpenACS 4.6.2" openacs OpenACS openacs-4-6-2 (that doesn't look exactly right but I don't have my notes in front of me) and cvs checkout -d openacs-upgrade -jpre_4-6_2_upgrade -jopenacs-4-6-2 openacs. Is this asking CVS to compare apples to oranges? My custom packages (which are in pre_4-6_2_upgrade should never be on the vendor branch, and what I imported as openacs-4-6-2 isn't really a proper vendor branch anyway, correct?
Can I work around this by tagging everything but my packages with OpenACS, then proceeding more verbatim with the upgrade instructions?
It might be helpful if you showed us the results of doing "cvs
stat -v" on, say, your "readme.txt",
"packages/acs-tcl/tcl/00-database-procs.tcl", and
"packages/my-custom-package/tcl/my-procs.tcl" files.
More critically: Have you customized any OpenACS files? Or has all your work been strictly the addition of your own packages? If you have not customized any files, then getting the CVS details right doesn't really matter, you should be able to do whatever and you'll still end up with a working website. However, if you've customized a bunch of OpenACS files then you'll tend to want to get the CVS operations right in order to help you with the merging, resolving of conflicts, etc.
(Note also that I'm rusty at this. My gut feel is that you should not normally be getting that "scheduled for removal" message, but I haven't actually tried it, so I could be mistaken.)
The central question is, how did you set up your OpenACS 4.5 site in the first place...
Part of the problem is obviously that I didn't set it up, so I'm not as familiar with it as I should be.
It might be helpful if you showed us the results of doing "cvs stat -v" on, say, your "readme.txt", "packages/acs-tcl/tcl/00-database-procs.tcl", and "packages/my-custom-package/tcl/my-procs.tcl" files.
Here's readme.txt ("packages/acs-tcl/tcl/00-database-procs.tcl") is the same:
===================================================================
File: readme.txt Status: Needs Patch
Working revision: 1.1.1.2
Repository revision: 1.1.1.3 /home/cvshome/acs-devel/bma/readme.txt,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
openacs-4-6-2-b (revision: 1.1.1.3)
openacs-4-6-2 (revision: 1.1.1.3)
pre_4-6-3_upgrade (revision: 1.1.1.2)
preview2 (branch: 1.1.1.2.4)
preview (branch: 1.1.1.2.2)
openacs-4-6 (revision: 1.1.1.2)
intranet-1_0 (revision: 1.1.1.1)
openacs-4-x-2002-01-10 (revision: 1.1.1.1)
OpenACS (branch: 1.1.1)
So I do have the expected "OpenACS" branch! "preview" and "preview2" are a couple of branches I set up trying to figure out how to use branches, "pre_4-6-3_upgrade" is the one I mentioned above (the 4_6_3 is a typo, I meant it to be 4_6_2) and "openacs-4-6-2" and "openacs-4-6-2-b" are two imports I did according the the current upgrade instructions. "openacs-4-6-2-b" is the one I'm using.
More critically: Have you customized any OpenACS files?
A few, but just a little. So few that it wouldn't take any time to hunt down the changes and redo them after an upgrade if need be.
Or has all your work been strictly the addition of your own packages?
Here lies the problem. The most important custom package is called intranet, and it's for -- no surprise -- our intranet. I work on it a lot, but I didn't create it, and it is on the OpenACS branch, though it shouldn't be:
===================================================================
File: intranet-procs.tcl Status: Up-to-date
Working revision: 1.10
Repository
revision: 1.10
/home/cvshome/acs-devel/bma/packages/intranet/tcl/intranet-procs.tcl,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
pre_4-6-3_upgrade (revision: 1.10)
preview2 (branch: 1.9.4)
preview (branch: 1.9.2)
intranet-1_0 (revision: 1.5)
openacs-4-x-2002-01-10 (revision: 1.1.1.1)
OpenACS (branch: 1.1.1)
I won't name names, but LP, you know who you are 😊. I compared this to a package I did create, bma-contacts and found:
===================================================================
File: index.adp Status: Up-to-date
Working revision: 1.4
Repository
revision: 1.4 /home/cvshome/acs-devel/bma/packages/bma-contacts/www/index.adp,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
pre_4-6-3_upgrade (revision: 1.4)
preview2 (branch: 1.4.4)
preview (branch: 1.4.2)
intranet-1_0 (revision: 1.4)
Now this gave me an idea (since I'm learning as I go). If I do the checkout with -jpre_4-6-3_upgrade -jopenacs-4-6-2-b everything in intranet and bma-contacts gets scheduled for removal. If I do it with -jOpenACS:yesterday -jopenacs-4-6-2-b, then bma-contacts does not get scheduled for removal, just upgraded (what I want), though intranet gets scheduled for removal, since it part of my "OpenACS (branch: 1.1.1)" but not part of the 4.6.2 distribution I just imported.
So what I need to do is get /web/bma/packages/intranet/ out of the OpenACS branch, along with a few other things. Is that possible? Or would I have to do something like create an OpenACS2 branch, only adding those things that should be on the OpenACS branch, and then use that branch for upgrading?
Ideally you could just somehow retroactively move your intranet package off the vendor branch, but off hand I can't think of any good way to do that without losing all your CVS version history.
Hm, you know, the easiest thing might be to make sure that all files in your intranet package have been committed since their original bogus import onto the vendor branch. Rather than actually checking that, you could just ensure that it is true by blindly forcing a commit of all files with "cvs commit -f -R intranet". Then when you do the vendor import of the newer version of OpenACS, you may still get the "scheduled for removal" message, but when you actually merge the changes across to the Head and commit, none of your files will be removed, because they'll all be newer than the versions on the vendor branch. I think.
With that scenario, in CVS it looks as if OpenACS released an intranet package, but then orphaned it, and you've picked up development since then and are now the only maintainer of the package. Which is fine, basically, as long as you never vendor import anything else call "intranet" onto that OpenACS vendor branch, you should be ok going forward.
Oh, one more thing: That tag name "openacs-4-x-2002-01-10" strongly implies that whoever first set things up did not import the official OpenACS 4.5 release, but rather some CVS snapshot pre-dating the 4.5 release. So you may need to triple check that the 4.5 to 4.6 upgrade scripts actually work correctly for you... I'd start by just figuring out what if any differences are present between "openacs-4-x-2002-01-10" and the official 4.5 release.
Andrew,
Thanks for your help, it turns out to be a big deal about nothing. Since we do have an OpenACS vendor branch, I made a copy of my CVS repository for testing and followed the upgrade instructions verbatim. Nothing was "scheduled for removal" and my intranet package was not touched (and none of my changes even caused conflicts). As I suspected at the outset, I just didn't know what I was doing.
I will have to watch out, as you say, for a new intranet package showing up in the distribution. There used to be an intranet package, but our package of the same name has nothing to do with that. I preface all my packages with bma- to avoide collisions, so I would be good to rename this package to bma-intranet, but that's a topic for another thread.
Thanks again!
