Re: Patch for CVS 1.11.17 and CVS 1.12.9 that allows for actions using specific versions of CVSROOT/modules
Mark D. Baushke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Turner <[EMAIL PROTECTED]> writes: Here at InfoInterActive, we've created a patch to allow us to better manage our modules. Our issue was that if you had to reproduce a build, there was no guarantee that the current version of a module fully encompassed what it did at the time the software was tagged. To rectify that we now tag CVSROOT/modules when we tag our software and wrote a patch that causes CVS to use a particular version of the modules file on checkout, export, etc. Now, if the CVSROOT/modules file it tagged at the time the software is built, we should now be able to re-create that build even if the module has been changed in the future. Hi Shane, You are addressing a problem that a number of folks consider a weakness of the modules file. However, as this is a new feature and not a remedy for an existing bug, it will not be added to the cvs 1.11.x branch and will only be considered for addition in the cvs 1.12.x feature branch. If possible, patches should be made against the CVS top-of-tree from cvshome.org. Exactly what I expected actually. I mailed out the 1.11.17 patch in case there are others (like our company) out there who haven't switched to 1.12.X but would like to try out the patch. As far as patching against the top-of-tree, I've tried to get access to the CVS repository on www.cvshome.org, but it has never worked. If I log in there then I can't do a damn thing. I've emailed to the webmaster (the only contact info I could find) and have never heard back. So this was the best I could do. If you can get my read-only access working, I'll gladly re-work the patch. All that said, I have not looked closely at your patch yet (and I probably won't have any time in the next few weeks myself, so if one of the other maintainers gets to it first that would be fine with me). I do have one comment/question for discussion... Would it be reasonable to extend the patch to also deal with '-D' times in conjunction with the -M ? So that if '-M branch' is used, then the branched version of the modules file is used and if -D and -M are used, then the version of the modules at that point in time on that branch are used... Note: A CVSROOT/modules file that was not branched or tagged will also need to do something reasonable given a '-M rev' flag. I'd like to extend it to take '-D' times, but I haven't worked at that yet. We currently only require using a date or revision. If we're stuck, we can determine the revision on a given date and use that. The -M flag will take a tag or a normal revision number so if you don't have a tag to use, you aren't stuck. Shane -- Shane Turner, Senior Software Engineer | InfoInterActive Corp. (An AOL Company) E [EMAIL PROTECTED] | W www.infointeractive.com AIM: iiaShane ICQ: 60761162| V: 902-832-2633 F: 902-832-1015 -BEGIN GEEK CODE BLOCK- GCS d-(+) s: a- C++$ ULS++ P+(++) L++ E@ W+ N o? K? w O M- V !PS !PE Y+ PGP t++@ 5+ X+ R tv b+ DI+ D+ G e++ h--- r+++ y+++ -END GEEK CODE BLOCK- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS best practice
Jim.Hyslop wrote: Rick Genter wrote: The system I work on consists of a number components. Each component is a separately built Java application, all referencing portions of a common database. Different components use different tables; some tables are shared by many components, while some are used by a single component. Over the life of the system, schema changes on the same table may have been required by different applications for different purposes. We script all of our database changes and store the scripts in our repository, but this has led to some "spirited" debate about repository structure. Our DBA wants to have a database-centric repository hierarchy where all database scripts are stored in a CVS module named for the database to which the script applies. There would be submodules for Tables, Stored Procedures, Indexes, etc. I, on the other hand, want scripts associated with a particular application to be stored in "SQL" or "Schema" submodule under the module for that application. In this case, you can have your cake and eat it, too! Follow the DBA's suggestion: create a completely independent CVS module that contains all the schema scripts. This keeps all the scripts in one place, and ensures that the schema is consistent. Whether you go to the extent of having a subdirectory for Tables, another for Stored Procs, etc. is between you and your DBA. In each of the projects that uses the database, add an "ampersand module" that points to the schema module to each project in CVSROOT/modules file that needs it. See the documentation for more details: https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC159 End result: The DBA gets to see all the files in one location, and you get to see the schema files with each project. If one project changes the schema, the other projects automatically inherit it. Everyone goes home a winner! I second Jim's suggestion. It answers your question much better than my response :) Shane -- Shane Turner, Senior Software Engineer | InfoInterActive Corp. (An AOL Company) E [EMAIL PROTECTED] | W www.infointeractive.com AIM: iiaShane ICQ: 60761162| V: 902-832-2633 F: 902-832-1015 -BEGIN GEEK CODE BLOCK- GCS d-(+) s: a- C++$ ULS++ P+(++) L++ E@ W+ N o? K? w O M- V !PS !PE Y+ PGP t++@ 5+ X+ R tv b+ DI+ D+ G e++ h--- r+++ y+++ -END GEEK CODE BLOCK- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS best practice
Rick Genter wrote: My question is more a question of best practice as opposed to how to use CVS. The system I work on consists of a number components. Each component is a separately built Java application, all referencing portions of a common database. Different components use different tables; some tables are shared by many components, while some are used by a single component. Over the life of the system, schema changes on the same table may have been required by different applications for different purposes. We script all of our database changes and store the scripts in our repository, but this has led to some "spirited" debate about repository structure. Our DBA wants to have a database-centric repository hierarchy where all database scripts are stored in a CVS module named for the database to which the script applies. There would be submodules for Tables, Stored Procedures, Indexes, etc. I, on the other hand, want scripts associated with a particular application to be stored in "SQL" or "Schema" submodule under the module for that application. What do others do? -- Rick Genter Sr. Software Engineer Silverlink Communications <mailto:[EMAIL PROTECTED]> (781) 272-3080 x242 Here we treat the database as its own application with interfaces defined by the stored procedures. The stored procedures let us change the schema without necessarily changing the stored procedures used by the applications. If the interface to the database needs to change for an application, then that requires a release of the database before or at the same time as the application release. We also aim to ensure that when an application requires a new interface the existing interface continues to exist until that new application is in place. This helps us de-couple the database from the applications. Of course things don't always work that cleanly, but that's usually due to a more radical than usual shift in schema. I hope that helps, Shane -- Shane Turner, Senior Software Engineer | InfoInterActive Corp. (An AOL Company) E [EMAIL PROTECTED] | W www.infointeractive.com AIM: iiaShane ICQ: 60761162| V: 902-832-2633 F: 902-832-1015 -BEGIN GEEK CODE BLOCK- GCS d-(+) s: a- C++$ ULS++ P+(++) L++ E@ W+ N o? K? w O M- V !PS !PE Y+ PGP t++@ 5+ X+ R tv b+ DI+ D+ G e++ h--- r+++ y+++ -END GEEK CODE BLOCK- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Patch to better handle deeply nested module definitions
Hi,
Here at InfoInterActive we've gotten into the habit of defining modules
for each library so when that library module is checked out, all of the
library modules that it depends on are also checked out. The problem
with this is when the same module ends up included more than once. When
accessing the repository on the local disk everything looks fine. When
you use ssh, things get wierd. After a given module is checked out for
the first time, every instance after that results in compaints because
it tried to check out the files all over again.
Here's an example of a the type of module definitions we use:
App -a Basics WunderLogLib FooLib BarLib AppDir
WunderLogLib -a Basics WunderLogLibDir
FooLib -a Basics WunderLogLib FooLibDir
BarLib -a Basics WunderLogLib FooLib BarLibDir
Basics -a BasicsDir
The unpatched cvs-1.11.1p1 would check out the following:
BasicsDir
BasicsDir
WunderLogLibDir
BasicsDir
BasicsDir
WunderLogLibDir
FooLibDir
BasicsDir
BasicsDir
WunderLogLibDir
BasicsDir
BasicsDir
WunderLogLibDir
FooLibDir
BarLibDir
AppDir
As you can see things get a little redundant.
To solve the problem, a couple of the other developers (Brad Spencer and
David Benoit) got sufficiently annoyed and wrote a little patch that
lets the server remember what modules it has already checked out.
We couldn't think of a better test for this new feature than the ones
that already test the module handling, so there isn't one.
I've submitted this patch to devel-cvs in the past, but I never did get
a response. I figure it's been working fine for us for months (and we
really push the envelope for modules) so it's safe for public
consumption.
Have fun and feel free to contact me if you have any questions or
suggestions.
Shane
--
Shane Turner, Senior Software Engineer
InfoInterActive Corp. (An AOL Company) www.infointeractive.com
E [EMAIL PROTECTED] V 902-832-2633 F 902-832-1015
AIM iiaShane
-BEGIN GEEK CODE BLOCK-
GCS d-(+) s: a- C++$ ULS++ P+(++) L++ E@ W+ N o? K? w O M- V !PS !PE Y+
PGP
t++@ 5+ X+ R tv b+ DI+ D+ G e++ h--- r+++ y+++
-END GEEK CODE BLOCK-
*** modules.c.orig Thu May 10 11:28:41 2001
--- modules.c Fri May 11 14:20:11 2001
***
*** 53,60
--- 53,170
static int sort_order PROTO((const PTR l, const PTR r));
static void save_d PROTO((char *k, int ks, char *d, int ds));
+ /*
+ * Remember what modules we've processed before so we don't duplicate a _lot_
+ * of effort. This saves an amazing amount of time with highly recursive
+ * module definitions. This should perhaps be a hash of some form, but
+ * writing complex data structures in C is just too quaint.
+ *
+ * GOTCHA: This assumes that only one (top-level) do_module is called per
+ * instance. If this isn't true, reset the table first. FIXME: It leaks.
+ */
+ /* Extra diagnostics */
+ #define CVSMODULE_PRINT_MODULE_MEMORY 1
+
+ /* Right now, it's just a linked list. */
+ struct MemoryNode {
+ struct MemoryNode *next;
+ char data[1];
+ };
+ static struct MemoryNode *st_list = NULL;
+ static unsigned int st_memoryHits = 0;
+
/*
+ * Ask if the specified module is in module memory or not.
+ */
+ static int
+ module_memory_hit(char *mname)
+ {
+ /* The current list */
+ struct MemoryNode *start = st_list;
+
+ /* Start at the front and see if it's there. If not, add it. */
+ while(start != NULL) {
+ if(strcmp(start->data, mname) == 0) {
+ /* Found it. */
+ st_memoryHits++;
+ return 1;
+ }
+ start = start->next;
+ }
+ return 0;
+ }
+
+ /*
+ * Add a specified module to module memory. Returns 1 if it was already there,
+ * or 0 if it wasn't.
+ */
+ static int
+ module_memory(char *mname)
+ {
+ /* The current list */
+ struct MemoryNode *node;
+
+ if(module_memory_hit(mname) == 1) {
+ return 1;
+ }
+
+ /*
+* Make a new node that will go on the front of the list. We've got the +1
+* in the data[1].
+ */
+ node = (struct MemoryNode *)xmalloc(sizeof(struct MemoryNode)
+ + strlen(mname));
+ node->next = st_list;
+ strcpy(node->data, mname);
+ st_list = node;
+
+ #if CVSMODULE_PRINT_MODULE_MEMORY
+ if(trace) {
+ cvs_outerr(CLIENT_SERVER_STR, 0);
+ cvs_outerr("-> Added module `", 0);
+ cvs_outerr(mname, 0);
+ cvs_outerr("' to module memory\n", 0);
+ }
+ #endif /* CVSMODULE_PRINT_MODULE_MEMORY */
+
+ /* We added it, so it wasn't there */
+ return 0;
+ }
+
+ /*
+ * Forget all current module memory
+ */
+
+ static void
+ module_memory_forget(void)
+ {
+ struct MemoryNode *node = st_list;
+ struct MemoryNode *next;
+
+ /* Delete all nodes */
+ while(node != NULL) {
+ next = node->next;
+ free(node);
+ node = next;
+ }
+ /* Mark the list as empty */
+ st_list = NULL;
+ st_memoryHits
Re: CVS tag renaming
Sandra Wittenbrock wrote: > Is it possible to rename a tag or branch? > > Thanks, > > Sandra If you want to give a _branch_ a new name, you will need to use the command "cvs admin" using the following procedure: Checkout the affected files using the existing branch name. Use the command cvs admin -nNEW_BRANCH_TAG:OLD_BRANCH_TAG to give the branch the second name "NEW_BRANCH_TAG". It won't work if the tag NEW_BRANCH_TAG has already been used. If it is already in use, then you will need to use cvs admin -NNEW_BRANCH_TAG:OLD_BRANCH_TAG Now you can check out the branch using OLD_BRANCH_TAG or NEW_BRANCH_TAG. If you wish to, you may now remove the OLD_BRANCH_TAG. Shane
Re: CVS/ENTRIES and cvs release
Shawn, I've found "cvs release" rather useless except when releasing the entire working directory. If I want to get rid of a directory in my working directory I ususally do the following, which updated the CVS/Entries file correctly: cvs update -r 0 -P directory_to_remove One issue with this technique is that it doesn't deal with the subdirectory having edited files, etc., but if things haven't been touched, it works fine. Shane Shawn Anderson wrote: CVS running on Unix [Solaris] Suppose you have a subdirectory in your working copy that you no longer wish to keep under cvs control. cvs release foo [where foo is the said directory] rm -rf foo Later on, you wish to run cvs status, but the stat aborts because foo, which exists in the CVS Entries file for its parent, does not exist in the directory hierarchy. How to work around this problem?? We've tried cvs release -d foo, but we still get the error when running the stat [and, I'd imagine, virtually any other command that is driven by the CVS/Entries file. Thanks in Advance
Re: Files created on Branch
Roy Miller wrote: > --- In [EMAIL PROTECTED], Shane Turner <[EMAIL PROTECTED]> wrote: > > One way to work around the problem is to put the ",v" file in the > repository into the Attic. > > > > Shane > > This is really not the way to operate cvs - try getting used to using > cvs commands. Otherwise, you might as well just be your own revision > control system, using rm, cp, mv, diff, etc. > I think you missed the point. CVS has gotten into a bad state. After the merge, the file is marked as being added. Upon attempting to commit, CVS is failing out because the RCS file in the repository is not in the Attic. The RCS file in the repository should be in the Attic if the top revision on the main line of development is dead. So. Given the top revision is dead and the RCS file in the repository is NOT in the Attic where it should be, we have to put it there in order to make CVS happy. Then when the commit is made, CVS moves the RCS file back out of the Attic. How CVS ended up with the RCS file in the wrong place hasn't been determined. It might be a bug. > > > > > "Kevin C. Castner" wrote: > > > > > I have files that were created on a branch > > > > > > (Create the file) > > > cvs co -r branch_name doc > > > cd doc > > > touch index.htm > > Here you imply the file index.htm already exists and is checked out > in > the doc directory. > No. He's demonstrating how he added a file on a branch instead of on the trunk. If your working directory is on a branch, any file created in that working directory and added is created on the trunk as a dead revision, and a regular revision on the branch. For example, in the case above, revision 1.1 of index.htm is dead and 1.1.2.1 is not. > > > > cvs add index.htm > > Then there is no need to "cvs add" the file - it already exists under > cvs control > See above. It did not exist and did require adding. > > > > cvs commit index.htm > > > > > > Now I try to merge the file back to the main trunk. > > > > > > cd .. > > > rm -rf doc > > > cvs co doc > > > cd doc > > It isn't necessary to remove your working directory and checkout a > "new" copy of project. You can revert to the main trunk simply by: > > cvs update -A > from within the doc directory > Valid point. > > > > cvs update -j branch_name > > > cvs commit index.htm > > > > > > CVS then gives me the following error: > > > > > > cvs server: cannot add file `index.htm' when RCS file > `/export/home/cvs/netops/doc/index.htm,v' already exists > > > cvs [server aborted]: correct above errors first! > > This part appears to be complaining about the scheduled addition of > an > already existing file (see comments above). > > Good luck, > Henry Nope. This is where the problem is being demonstrated. The RCS file isn't in the correct place in the repository. My guess (and I haven't tested this yet) is that when the file is added on the branch, the RCS file is not created in the Attic although the revision on the trunk is dead, which implies that the RCS file should be in the Attic. Shane Turner
Re: Files created on Branch
We are using 1.10.8 in local mode and via rsh. Shane Eric Siegerman wrote: > Which version of CVS? I just tried this using 1.10.8 and it > worked fine.
Re: Files created on Branch
We just experienced that same problem here. I haven't had a chance to investigate the cause. One way to work around the problem is to put the ",v" file in the repository into the Attic. Shane "Kevin C. Castner" wrote: > I have files that were created on a branch > > (Create the file) > cvs co -r branch_name doc > cd doc > touch index.htm > cvs add index.htm > cvs commit index.htm > > Now I try to merge the file back to the main trunk. > > cd .. > rm -rf doc > cvs co doc > cd doc > cvs update -j branch_name > cvs commit index.htm > > CVS then gives me the following error: > > cvs server: cannot add file `index.htm' when RCS file >`/export/home/cvs/netops/doc/index.htm,v' already exists > cvs [server aborted]: correct above errors first! > > Thanks > > Kevin
Re: Hypothetical: Adding the first file in a repository on a branch
Eric Siegerman wrote: > On Wed, Jun 14, 2000 at 03:48:08PM -0300, Shane Turner wrote: > > The only way that a file can be added on a branch is if there exists a > > file on that branch. Having that first file allows you to update to the > > branch. > > > > So, since the only thing that seems to matter is whether or not the tag > > exists in val-tags, then shouldn't there be a way to manage valid tags? > > "cvs tag -b branch" appears to succeed when performed in an empty directory: > $ ls -la > total 6 > drwxr-xr-x 3 ericswww 512 Jun 14 18:04 . > drwxr-xr-x 4 ericswww 512 Jun 14 18:04 .. > drwxr-xr-x 2 ericswww 512 Jun 14 18:04 CVS > $ cvs tag -b branch > cvs tag: Tagging . > $ echo $? > 0 > $ > > It would suffice if this also added "branch" to val-tags. That would certainly do the job. Shane
Hypothetical: Adding the first file in a repository on a branch
I'm sure many of us have added a file on a branch such that the file only exists on the branch and exists on the trunk as a dead revision. While trying to set up a test case to diagnose a problem a developer was having, I tried the following: 1. Created a test repository. 2. Created a working directory. 3. Checked out the root directory non-recursively. Now at this point I wanted to add a file, but only on a branch. I wanted a dead revision on the trunk. >From what I can tell it isn't possible via the standard CVS commands. The only way that a file can be added on a branch is if there exists a file on that branch. Having that first file allows you to update to the branch. The consequence of updating to the branch is that the CVS/Tag file is created in the working directory with the name of the branch to commit to. At that point when you create a file, add it, and commit it, the RCS file for the added file is created in the Attic with a dead revision on the trunk and the file as it was added on the branch revision. I just had a possible way to do it. (just a sec) Ok. You can do it by manually creating CVS/Tag containing "Tbranchtag" where "branchtag is the tag you want to add the file on. Or. You can add the tag you want to add files on to $CVSROOT/CVSROOT/val-tags by adding a line of the format "branchtag y". So, since the only thing that seems to matter is whether or not the tag exists in val-tags, then shouldn't there be a way to manage valid tags? Maybe something to validate val-tags? Admittedly, I doubt this concerns anyone. I just thought that it was odd to require a file be already on a branch before adding new files to the branch. Shane Turner
Re: Diff bug when using the HEAD tag?
Martin Roehrig wrote: > Pardon me if I ask a silly question, but how could a single revision be > present on multiple branches? As far as I understood the revision number > exactly defines where the revision belongs to, doesn't it? > When you apply a branch tag to a file, my interpretation is that the revision that was tagged (the origin of the branch) is on the branch. If you make that revision the origin of many branches, it is on each of those branches. Shane
Re: Diff bug when using the HEAD tag?
"Cameron, Steve" wrote: [ DELETED STUFF ] > HEAD as described here definitely has some impossible > or at least meaningless cases: for instance, a sticky, > non-branch tag (or date or revision) on a file could > match a revision that is present on multiple branches, > so which is the "correct" current branch for which the > tip revision should be found? There's no sensible answer. > I suppose that could be treated as an error and CVS > could say, in essence, "you've asked me a nonsense > question." for such files. Seems more trouble than > it's worth to me though. I think my approach would be that non-branch tags would be treated as the top of a branch with no revisions commited to it. Therefore, for a file that is checked out on the non-branch tag, the difference between it and HEAD would be empty. Now for a file that has not been checked out with a tag, I think the difference would have to be against the top of the trunk.
Re: forced updates
Just delete the file. CVS will notice that it is missing and fetch a fresh copy from the repository. The other option is to "cvs edit" the file, then "cvs unedit" when you are done with it. Both of these are available in the WinCVS interface. The "cvs edit" saves a copy of the file. The "cvs unedit" will prompt you to see if you want to overwrite the modified file. In the situation that you are asking about, you would just answer yes. Shane "Dimitrie O. Paun" wrote: > > Hi, > > Very often I run in this problem: I edit some files to add debugging stuff, > and after a while I want to updated from CVS and to simply _overwrite_ the > changes I made. > > I know, I can delete the files and then update. But, this is difficult > 'cause sometimes I don't know what I've modified (and the files are > scattered in hundreds of directories). Questions: > > 1) can I do this in one shot? > 2) can I do it on the command line? > 3) can I do it in WinCVS? > > TIA, > Dimi.
Re: Diff bug when using the HEAD tag?
I think what you are seeing is related to the way that diff handles the meaning of the tag HEAD. Like someone mentioned already, diff sees HEAD as being the latest version on the current branch. I personally think it still lies. Say I have file1 that has two revisions 1.1 and 1.2. There is a branch (BRANCH1) based off of revision 1.1. Say I check out BRANCH1. This results in my getting revision 1.1 of file1. Now I try diffing against HEAD. cvs diff -r HEAD file1 As stated before, this should give me the difference between my current revision on the branch (1.1) and the top revision on the branch (also 1.1). But it doesn't It actually gives me the diff between 1.2 and 1.1. Now if I ran cvs diff -r BRANCH1 file1 I get the correct result. Seems like a bug to me. Now back to your situation: When you are on the TRUNK, you can only do the difference using the branch tag, so everything works as expected. When you are on the BRANCH1 some of the files actually have revisions commited onto the branch, but some of them still only have revisions on the TRUNK. When you diff against the HEAD tag, the files that don't have revisions on the branch, the diff follows the TRUNK for those files. The result is a hybrid diff of things that have changed on the branch and things that have changed on the TRUNK. Hopefully everything made sense. Shane "Deever, Chris C." wrote: > >When you're working on a branch, "HEAD" means the head of the branch, > >not the head of the trunk, at least for diff. > > >-Larry Jones > > Please forgive me if I'm not yet on the same page, but I can't seem to fit > that explanation into my scenario. > > The diff from the branch to HEAD *did* report some of the changes, except > for two changes that happened to be in a file which there are in two > different copies of the same file located in different parts of the project > (a shared data structure between client and server). > > new branch > | > base line version -> rel tag -> a little more development -> current > > The above shows the tree. When I am in "current" and diff against "new > branch" I see all of the changes that I expect. However, when I am in, "new > branch" and I diff it against HEAD (which I am expecting it to be the latest > changes comitted in the repository), I see only part of the changes. > > Either there is a bug or I'm not understanding something. Branches do not > automatically get changes from the trunk, do they? > > Regards, > > Chris
Re: TIP on removing directories from working directory
Someone here suggested the same thing. At first I didn't think that it updated the parent's CVS directory, but I was wrong. It creates the file Entries.Static which tells CVS not to update directories that aren't already checked out. However, the method I suggested works for files, not just directories whereas "cvs release -d" only works on directories. Shane Jerry Nairn wrote: > Thanks, > That's pretty cool. I'm thinking of how it would be an improvement over "cvs > release -d"ing the unwanted folders, though. Doesn't that update the > CVS/Entries file? > Jerry > > > -Original Message- > > From: Shane Turner [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 24, 2000 5:15 AM > > To: [EMAIL PROTECTED] > > Subject: TIP on removing directories from working directory > > > > > > I've often wanted to check out a module, then prune off the > > directories > > and files that > > I didn't need. Until the other day I couldn't figure out a > > way to do it > > entirely with CVS commands. > > > > What I had been doing is deleting the directory that I didn't > > want, then > > manually updating the CVS/Entries file of the parent. This > > just seemed > > wrong. > > > > The other day I realized that I could use the same mechanism > > used in the > > suggested 'cvs ls' equivalent (cvs rdiff -s -r 0 module). I > > could cause > > CVS to discard the files I didn't want by specifying a non-existant > > revision, and prune empty directories. > > > > cvs update -r 0 -P file-or-directory-to-remove > > > > Hopefully someone else will find this useful. > > > > Shane > >
TIP on removing directories from working directory
I've often wanted to check out a module, then prune off the directories and files that I didn't need. Until the other day I couldn't figure out a way to do it entirely with CVS commands. What I had been doing is deleting the directory that I didn't want, then manually updating the CVS/Entries file of the parent. This just seemed wrong. The other day I realized that I could use the same mechanism used in the suggested 'cvs ls' equivalent (cvs rdiff -s -r 0 module). I could cause CVS to discard the files I didn't want by specifying a non-existant revision, and prune empty directories. cvs update -r 0 -P file-or-directory-to-remove Hopefully someone else will find this useful. Shane
Re: Renaming branch?
The only way that I know of to rename a branch tag is using cvs admin. cvs admin -nbranch-name:new-branch-name You'll need to have the files checked out unfortunately. I don't think that there is a way to rename the branch in any file that has been deleted on the branch. Shane -- Shane Turner, Developer, InfoInterActive V 902-832-2633 F 902-832-1015 W http://www.infointeractive.com E mailto:[EMAIL PROTECTED]
Re: Renaming a branch tag
Stephen Rasku wrote: > Is it possible to rename a branch tag? We have been developing new > features on a brach, called rel-2_4, while just performing bug fixes > on the head. I am in the process of merging this branch to the head. > I have created another branch from the current head called rel-2_3 so > that we can continue to fix bugs in version 2.3 of the product if we > need to. > > However, when we start doing 2.5 development, if I create a new 2.4 > branch called rel-2_4, it will leave the old 2.4 branch inaccessible. > I would like to rename the rel-2_4 branch to rel-2_4-orig (or > something like that). > > -- > Stephen Rasku E-mail: [EMAIL PROTECTED] > Senior Software EngineerPhone: (604) 872-6676 > TGI TechnologiesWeb:http://www.tgivan.com/ Hi Stephen, I believe what you want to do can be done with cvs admin. The command cvs admin -nrel-2_4-orig:rel-2_4 will result in the revisions tagged as rel-2_4 also being tagged as rel-2_4. So if branch rel-2_4 on file1 is revision 1.1.0.2 (shows up in cvs status as branch: 1.1.2), that same revision will have a second name rel-2_4-orig. Essentially an alias. I haven't found any other way to do this. Shane -- Shane Turner, Developer, InfoInterActive V 902-832-2633 F 902-832-1015 W http://www.infointeractive.com E mailto:[EMAIL PROTECTED]
