Re: recursive add
Hello,
an answer to an older post:
* On Tue, Mar 01, 2005 at 10:59:32AM -0800 Wei Shi wrote:
Maybe this question has been brought up before. Is
there a recursive add command in CVS?
I'm not sure what you mean with recursive add. Possibly, the following
commands might accomplish what you want to do:
$ cvs add `find . -type d`
$ cvs add `find . -type f`
(I expect you are running on a Unix box, or with Cygwin on Windows)
If there are too much files/directories, you might encounter problems
with the maximum line length of the shell interpreter. In this case,
replacing the second command with
$ find . -type f -exec cvs add \{\} \;
is a good replacement, neglecting the fact this this command will be
much slower for a remote repository.
HTH,
Spiro.
--
Spiro R. Trikaliotis http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
recursive add
Hi, Maybe this question has been brought up before. Is there a recursive add command in CVS? Thanks. Wei __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
recursive add ?!
hello, i have a simple question. i'm using wincvs 1.36 and wonder why i can not find a recursive add command? ok, i can use the import module command but therefore my new sources need to be outside the cvs controlled directory! but when i e.g. have a directory under controll called myproject and when i want to add a new class com/foo/Foo.class it would be create to select com and add the selection recursively?! is this possible?! when i want to write this functionality by myself. where do i start? should i use tcl or python. are there tutorial concerning the integration in e.g. wincvs?! thanks in advance, leif ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add ?!
On Fri, 12 Jul 2002, Leif Hanack wrote: hello, i have a simple question. i'm using wincvs 1.36 and wonder why i can not find a recursive add command? ok, i can use the import module command but therefore my new sources need to be outside the cvs controlled directory! but when i e.g. have a directory under controll called myproject and when i want to add a new class com/foo/Foo.class it would be create to select com and add the selection recursively?! is this possible?! I did it in Meta-CVS. :) Of course, the problem you run into is that the directory may contain all kinds of files, some of which need to be treated as binary. WinCVS has a dialog box in its import GUI where can verify and change the disposition of each file. when i want to write this functionality by myself. where do i start? should i use tcl or python. are there tutorial concerning the integration in e.g. wincvs?! For the sake of keeping the WinCVS program consistent, you would probably want to do it in that program, perhaps reusing the code which gathers up the file suffixes and throws them into a dialog box. I do a similar thing in Meta-CVS; both the create command for makign a new module, and the add command interactively deal with file types. Now the problem is that cvs import and cvs add do not have the same interface for specifying keyword modes. In import, you specify a wildcard match on file suffixes, allowing you to express the idea that all *.png files are to be treated -kb. In cvs add, you do not have this; the keyword expansion mode you specify applies to all file arguments. In Meta-CVS the problem is solved by collating all of the files into buckets based on their expansion mode, and then issue a cvs add command (or several, if the command line is too long) for each bucket. -- Meta-CVS: solid version control tool with directory structure versioning. http://users.footprints.net/~kaz/mcvs.html http://freshmeat.net/projects/mcvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add ?!
Leif Hanack wrote: hello, i have a simple question. i'm using wincvs 1.36 and wonder why i can not find a recursive add command? There isn't one. You have to add each new directory by hand before the contents of that directory can be added. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add ?!
Leif Hanack writes: i have a simple question. i'm using wincvs 1.36 and wonder why i can not find a recursive add command? Because CVS itself doesn't have a recursive add command? -Larry Jones I think grown-ups just ACT like they know what they're doing. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add
I m not an expert of nix command but : What the purpose of xargs, it redistribute the output of the command before | to the commande after ? a+ Karl E. Jorgensen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add
On Sat, Dec 15, 2001 at 01:53:28PM +0100, David D wrote: Is cvs add */*/* add three level directories ? Wonderful ! Yes, but it's nothing to do with cvs, only standard unix globbing. You can do 'echo cvs add */*/*' to see what the actual command line is. Which means it probably won't work on the windows command line client. Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add
On Mon, Dec 17, 2001 at 12:25:37PM +0100, David D wrote: I m not an expert of nix command but : What the purpose of xargs, it redistribute the output of the command before | to the commande after ? Exactly. It could probably also be done by this one: $ cvs add $(find . -type d; find . -type f) or $ cvs add $(find . -print) - if find prints the directories before the files in them. I think it does. Both of the above will run into problems if there are too many files. Then the shell will complain about the maximum command line length. xargs will chop it up to avoid that. -- PGP signed and encrypted| .''`. |** Debian GNU/Linux ** messages preferred. | : :' : |By professionals, www.karl.jorgensen.com| \. `' |for professionals | `-| http://www.debian.org/ msg15568/pgp0.pgp Description: PGP signature
Re: recursive add
Karl == Karl E Jorgensen [EMAIL PROTECTED] writes: Karl On Fri, Dec 14, 2001 at 03:03:34PM +0900, Alex Shinn wrote: Is there a way to recursively add directory hierarchies in cvs? The manual says to use import in this case, but that doesn't do what I want since I'm trying to add within a branch. Even if I specify the releasetag as an existing branch release, the files get imported into the main branch as well. Karl What about something like: Karl $ find . -type d -print | grep -v CVS| xargs cvs add Karl followed by Karl $ find . -type f -print | grep -v CVS | xargs cvs add Karl (assuming that all files are text) ?? Well, not all text, but I ended up doing something like this with File::Find. Thanks for the help Larry and Karl. Next question: can you add a tag within a branch (not a sub-branch)? -- Alex ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add
David D writes: Is cvs add */*/* add three level directories ? I'm not sure of your terminology -- it adds files and directories that are two levels below the current directory (provided the parent directories have already been added). -Larry Jones I don't think that question was very hypothetical at all. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: recursive add
On Fri, Dec 14, 2001 at 03:03:34PM +0900, Alex Shinn wrote: Is there a way to recursively add directory hierarchies in cvs? The manual says to use import in this case, but that doesn't do what I want since I'm trying to add within a branch. Even if I specify the releasetag as an existing branch release, the files get imported into the main branch as well. What about something like: $ find . -type d -print | grep -v CVS| xargs cvs add followed by $ find . -type f -print | grep -v CVS | xargs cvs add (assuming that all files are text) ?? -- Alex -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com Today's fortune: Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann msg15546/pgp0.pgp Description: PGP signature
Re: recursive add
Alex Shinn writes: Is there a way to recursively add directory hierarchies in cvs? cvs add * cvs add */* cvs add */*/* ... I think there have been scripts posted here as well -- you might want to check the archives. -Larry Jones It seems like once people grow up, they have no idea what's cool. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
recursive add
Is there a way to recursively add directory hierarchies in cvs? The manual says to use import in this case, but that doesn't do what I want since I'm trying to add within a branch. Even if I specify the releasetag as an existing branch release, the files get imported into the main branch as well. -- Alex ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Script for recursive add under Windows?
Hi! I've been using CVS for a while and there's one thing which I'm rather baffled by: the lack of a recursive add function, which would essentially do what you'd expect an intuitive combination of import and add to do. In lack of this functionality, I'm wondering if anyone has a shell script for DOS under Windows 2000 (yes, yes, I know, but life isn't perfect) which would do it? Or, in fact, any script or program which would run under a standard Win2000 install. Grateful for any help or information on the subject. Thanks, Daniel -- Daniel Aborg - Developer [EMAIL PROTECTED] M: +44 (0)7720 29 44 40 DDI: +44 (0)20 7451 1447 Netengines: +44 (0)20 7451 1444 www.netengines.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Script for recursive add under Windows?
[EMAIL PROTECTED] wrote: Hi! I've been using CVS for a while and there's one thing which I'm rather baffled by: the lack of a recursive add function, which would essentially do what you'd expect an intuitive combination of import and add to do. In lack of this functionality, I'm wondering if anyone has a shell script for DOS under Windows 2000 (yes, yes, I know, but life isn't perfect) which would do it? Or, in fact, any script or program which would run under a standard Win2000 install. Grateful for any help or information on the subject. Cut here: 8---8--8--- @ECHO OFF SETLOCAL REM Set up a string that specifies all files we want to check in SET cvs_add_list=*.cpp,*.c,*.pl,*.html,*.xml,*.txt,*.class,*.java,*.pm :parse_options if NOT %1==/? goto add_tree_head ECHO Adds a directory tree of files to CVS ECHO. ECHO ADD_TREE [directory] ECHO. ECHO If directory is passed, then that directory will be used as ECHO the root directory for the add operation - that directory ECHO and all sub-directories will be added. ECHO. ECHO Files are added according to the filter stored in the environment ECHO variable ADD_TREE_FILTER. If this is unset, the default value of ECHO %cvs_add_list% ECHO is used... ECHO. ECHO Files are added in each sub-directory. ECHO There is no way (today!) to specify exception files or exception directories. ECHO. ECHO Contributor: John Minnihan GOTO :EOF :add_tree_head set head_dir= %1 IF NOT DEFINED head_dir echo Adding subtree only... IF NOT DEFINED head_dir goto add_subtree IF NOT EXIST %1 @ECHO Bad File: %1 IF NOT EXIST %1 GOTO :EOF cvs add %1 CD %1 goto add_remainder_of_subtree :add_subtree @CD %1 :add_remainder_of_subtree ECHO. ECHO. ECHO. CD ECHO * ECHO Adding directories... ECHO * FOR /D %%i in (*) DO IF /I NOT %%i==CVS cvs add %%i ECHO * IF DEFINED add_tree_filter set cvs_add_list=%add_tree_filter% REM Note that because the cvs_add_list might not only contain REM wildcard search expressions, we could attempt to add a file REM that isn't there. Silly, but true. So we'll check. ECHO Adding files... ECHO * FOR %%i IN (%cvs_add_list%) DO IF EXIST %%i cvs add %%i ECHO * REM And recurse for all the directories below... FOR /D %%i IN (*) DO IF /I NOT %%i==CVS call :add_subtree %%i CD .. GOTO :EOF ENDLOCAL -- John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
[ On Thursday, September 20, 2001 at 22:00:31 (-0700), Paul Sander wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs --- Forwarded mail from Greg Woods: No, you don't have to check out a new sandbox. All the commit comment logs and previous revision deltas, old releases, etc. are all immediately and completely accessible, even without ANY working directory. I ran a little experiment, the transcript I've included at the bottom of this message. The gist is that Greg's claim technically is true, but not if CVS best practices are followed. The hiccup is that in order to see the complete version history, you can't prune empty directories in your workspace. Best practices include adding the -P option to your .cvsrc file for checkout and update, which always prunes. Paul: YOU DO NOT EVEN NEED ANY WORKING DIRECTORY TO SEE ALL HISTORY You certainly don't have to avoid any cvs best practices either. This assumes a couple of things: First, that the commit comments are meaningful enough, which is rarely the case. The procedure is documented clearly in the manual. If people don't read the manual and learn how to do this, as well as follow any additional local procedures properly, etc., then they probably shouldn't be working on the project in the first place as they are probably incompetent. If you only have incompetents to work with then it's not too hard to concoct a wrapper script to implement a packaged cvsrename feature that does everything for them (though of course if you're paranoid you'll never trust them to use it so you might just as well do everything yourself!). Furthermore if it's a multi-person project then you will have peer review and peer pressure, and if that doesn't work then nothing will and your project is probably doomed anyway. Second, to perform a merge across directories like this, it's necessary to either do the work by hand or create and apply context diffs, and we assume that developers are willing and able to do this. In my experience, developers prefer not to do the merge by hand, and they don't know about the patch(1) program which makes applying context diffs harder. You must live in some weird space warp Paul. Most programmers I know, and myself included, have been doing all of that without complaint for decades now. If it takes a swat with a clue-by-4 to get someone to do manual merges where necessary then you might want to think twice about having them on your team in the first place. People who don't know about 'patch' probably don't know about 'diff' either and obviously have not read the CVS manual (which mentions the 'patch' program and its uses explicitly in several places), probably shouldn't be allowed to use cvs, and certainly shouldn't be maintaining code where any merges are necessary, manual or otherwise # Now seek out version history dating back from before the rename # I want to see I WANT TO SEE THIS MESSAGE recorded in a/b/a.c's # version history. bugs(paul:.cshrc):a% cvs log hint: try cvs log a/b/a.c You will be able to discover the correct pathname to use courtesy the (re)birth comment you were supposed to have written in the first revision of the added file, i.e. the file who's pathname you do know. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
--- Forwarded mail from Greg Woods: [ On Thursday, September 20, 2001 at 22:00:31 (-0700), Paul Sander wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs --- Forwarded mail from Greg Woods: No, you don't have to check out a new sandbox. All the commit comment logs and previous revision deltas, old releases, etc. are all immediately and completely accessible, even without ANY working directory. I ran a little experiment, the transcript I've included at the bottom of this message. The gist is that Greg's claim technically is true, but not if CVS best practices are followed. The hiccup is that in order to see the complete version history, you can't prune empty directories in your workspace. Best practices include adding the -P option to your .cvsrc file for checkout and update, which always prunes. Paul: YOU DO NOT EVEN NEED ANY WORKING DIRECTORY TO SEE ALL HISTORY You certainly don't have to avoid any cvs best practices either. See the transcript below. Your turn to provide transcripts showing how you manage this without a sandbox. This assumes a couple of things: First, that the commit comments are meaningful enough, which is rarely the case. The procedure is documented clearly in the manual. If people don't read the manual and learn how to do this, as well as follow any additional local procedures properly, etc., then they probably shouldn't be working on the project in the first place as they are probably incompetent. If you only have incompetents to work with then it's not too hard to concoct a wrapper script to implement a packaged cvsrename feature that does everything for them (though of course if you're paranoid you'll never trust them to use it so you might just as well do everything yourself!). Furthermore if it's a multi-person project then you will have peer review and peer pressure, and if that doesn't work then nothing will and your project is probably doomed anyway. Only about 10% of the developers I know have ever opened the manual to their version control tool. They rely instead on quick reference cards and get by with the minimum effort. And peer reviews don't usually include commit comments at the moment they're written. They're either done before the commit if the policy is to commit only good code, or they're done after the commit when it's too late to edit the comments. Second, to perform a merge across directories like this, it's necessary to either do the work by hand or create and apply context diffs, and we assume that developers are willing and able to do this. In my experience, developers prefer not to do the merge by hand, and they don't know about the patch(1) program which makes applying context diffs harder. You must live in some weird space warp Paul. Most programmers I know, and myself included, have been doing all of that without complaint for decades now. If it takes a swat with a clue-by-4 to get someone to do manual merges where necessary then you might want to think twice about having them on your team in the first place. People who don't know about 'patch' probably don't know about 'diff' either and obviously have not read the CVS manual (which mentions the 'patch' program and its uses explicitly in several places), probably shouldn't be allowed to use cvs, and certainly shouldn't be maintaining code where any merges are necessary, manual or otherwise I think you're the one living elsewhere. In my world, merges are avoided like the plague, the developers preferring to minimize the number of large merges performed. CVS makes merging easier when sharing a branch, but the old habits when working on isolated branches remain. And every developer I know uses diff regularly. But they're familiar only with the standard Unix tools and plus the ones in their personal toolkits. They really are unaware of patch until I tell them about it. And no, they don't read the CVS manual because either a) they don't use Emacs, or b) they're not interested in learning all of the nuances of CVS (preferring instead to learn the minimum to get by). None of this means they're poor software engineers; it just means that they're more interested in solving their problems, not jumping through hoops with the uninteresting version control system. # Now seek out version history dating back from before the rename # I want to see I WANT TO SEE THIS MESSAGE recorded in a/b/a.c's # version history. bugs(paul:.cshrc):a% cvs log hint: try cvs log a/b/a.c You will be able to discover the correct pathname to use courtesy the (re)birth comment you were supposed to have written in the first revision of the added file, i.e. the file who's pathname you do know. Tried that. Didn't work without having a/b in the workspace. That meant having to do an update -d to get it. It's all in the transcript of my prior message. --- End of forwarded message from [EMAIL PROTECTED] # Let's see
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
[ On Friday, September 21, 2001 at 00:44:42 (-0700), Paul Sander wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs Only about 10% of the developers I know have ever opened the manual to their version control tool. They rely instead on quick reference cards and get by with the minimum effort. Then 90% of the developers you know are very poor engineers. No question about it. And peer reviews don't usually include commit comments at the moment they're written. Who says they have to be? Peer review is all about learning how to do it better next time so that your peers don't have to fix your mistakes. I think you're the one living elsewhere. In my world, merges are avoided like the plague, the developers preferring to minimize the number of large merges performed. CVS makes merging easier when sharing a branch, but the old habits when working on isolated branches remain. In my world, where software maintenance makes up 95% of every program's lifetime, merges of one form or another make up well over half of the work done. And every developer I know uses diff regularly. But they're familiar only with the standard Unix tools and plus the ones in their personal toolkits. They really are unaware of patch until I tell them about it. Then you should chastise them for not reading their manuals properly. And no, they don't read the CVS manual because either a) they don't use Emacs, Now you're really WAY off in hyperspace Paul. What the hell does emacs have to do with reading the friggin manual!?!?!?!?!? Have you neve heard of the dead tree version? How about the HTML version? Maybe you've forgotten there's a PDF too? And how anyone anywhere could ever confuse the 'info' browser with Emacs stuns me to no end! or b) they're not interested in learning all of the nuances of CVS (preferring instead to learn the minimum to get by). This isn't a bloody 'nuance' man! It's a prominently discussed tool in the manual! Why the number of times the word 'patches' alone appears should get anyone with two neurons to rub together to start asking what the heck they are and how to deal with them! None of this means they're poor software engineers; it just means that they're more interested in solving their problems, not jumping through hoops with the uninteresting version control system. I think you'd better go learn what it means to be an engineer. I might not be a Professional Engineer(tm), but I've been a practicing engineer (in the traditional definition) almost all of my life. I can assure you that if you don't RTFM then you cannot be an engineer, almost by definition, and certainly never a Professional Engineer(tm). (You could read the code, and be a better engineer, I guess, but I can't expect everyone to do that I guess.) hint: try cvs log a/b/a.c You will be able to discover the correct pathname to use courtesy the (re)birth comment you were supposed to have written in the first revision of the added file, i.e. the file who's pathname you do know. Tried that. Didn't work without having a/b in the workspace. That meant having to do an update -d to get it. It's all in the transcript of my prior message. OK, so there's a bug. Have you reported it? Do you have a fix? In the mean time cvs rlog modulepath/a/b/a.c will work (and without any working directory, obviously). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
[ On Friday, September 21, 2001 at 18:45:22 (-0700), Paul Sander wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs In the mean time cvs rlog modulepath/a/b/a.c will work (and without any working directory, obviously). Really? Here's the response I get: bugs(paul:.cshrc):paul% cvs rlog a/b cvs log: warning: the rlog command is deprecated cvs log: use the synonymous log command instead cvs [log aborted]: no such directory `a' Do you have any more ideas? You're running an old and broken version of CVS -- time to upgrade. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
--- Forwarded mail from Greg Woods: [ On Wednesday, September 19, 2001 at 19:30:19 (-0700), Paul Sander wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs 'Course, this procedure makes it harder to gather the entire version history of any file together into one place (you need to check out a new sandbox for every reorg to see it all) No, you don't have to check out a new sandbox. All the commit comment logs and previous revision deltas, old releases, etc. are all immediately and completely accessible, even without ANY working directory. I ran a little experiment, the transcript I've included at the bottom of this message. The gist is that Greg's claim technically is true, but not if CVS best practices are followed. The hiccup is that in order to see the complete version history, you can't prune empty directories in your workspace. Best practices include adding the -P option to your .cvsrc file for checkout and update, which always prunes. , and it's harder to merge between branches if the contributor branch didn't have this procedure done at the same time as the destination branch. Huh? Never been a problem for me (and yes, I've done it multiple times). I suppose if someone tried to do a merge without knowing what had happened they might be in for a bit of a surprise, but provided the commit comments are meaningful enough they should be able to figure out what to do quickly enough. This assumes a couple of things: First, that the commit comments are meaningful enough, which is rarely the case. Second, to perform a merge across directories like this, it's necessary to either do the work by hand or create and apply context diffs, and we assume that developers are willing and able to do this. In my experience, developers prefer not to do the merge by hand, and they don't know about the patch(1) program which makes applying context diffs harder. Another way to handle some of these cases is replicate the RCS files in the repository (and delete version tags), but that method has its own problems. Yup. The problems are almost as serious, and potentially even more serious if you've got other potential clashes with other dead files in the destination directory. Never replicate files in the repo and never make any links (hard or symlinks) in the repo! My experience has been that replicating the RCS files causes fewer problems than the remove/add method. If your developers expect the revision history to be complete after the rename without having to search through the workspace, and you're careful about managing your tags, it is a viable method. But your mileage may vary. Still another way is to write a new module and hack in the new location of the renamed directories. That solves the problems of both methods above, but adds its own set. For example, all users of the new module must perform a fresh checkout, plus you must track multiple modules for a single product. Yes, that works well enough in a few cases, but generally it simply migrates the problem to a place where CVS has no good support tracking release relationships (i.e. to the modules file). It also relies on complex features of the `modules' feature which may not be stable and which are known not to behave identically on client-server and local checkouts. Actually, the behavior of the modules database is defined well enough for it to work if you stick strictly to the documentation and don't try to be tricky. Alias modules and ampersand inclusion are sufficient and work reasonably well. But, as Greg suggests, you must track changes to the modules using a method other than tags. That means using ad-hoc naming conventions within the modules database. It's a pain, but it works in some cases. Again, your mileage may vary. I've used all three methods, and each has its strengths and drawbacks. Use the one that gives you the fewest problems. --- End of forwarded message from [EMAIL PROTECTED] Here's the transcript of my experiment: # Check out a module that contains just the directories a and a/b bugs(paul:.cshrc):testhome% cvs checkout a cvs checkout: Updating a cvs checkout: Updating a/b # Populate the a/b directory bugs(paul:.cshrc):testhome% cd a/b /usr2/paul/cvshome/cvs/src/testhome/a/b bugs(paul:.cshrc):b% echo This is the initial version of a.c a.c bugs(paul:.cshrc):b% cvs add a.c cvs add: scheduling file `a.c' for addition cvs add: use 'cvs commit' to add this file permanently bugs(paul:.cshrc):b% cvs commit -m I WANT TO SEE THIS MESSAGE a.c RCS file: /usr2/paul/cvshome/cvs/src/testroot/a/b/a.c,v done Checking in a.c; /usr2/paul/cvshome/cvs/src/testroot/a/b/a.c,v -- a.c initial revision: 1.1 done # Apply a tag to all files in the module bugs(paul:.cshrc):b% cvs tag REL1 a.c T a.c # Rename of a/b to a/c # Begin by creating a/c bugs(paul:.cshrc):b% cd .. /usr2/paul/cvshome/cvs/src/testhome/a bugs(paul:.cshrc):a% mkdir c bugs(paul:.cshrc):a% cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
i received a really cool trick for my problem: go to the repository directly (have a backup copy) rename the desired directory; do a fresh checkout and everything works fine; thanks alex John Minnihan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... This silly little batch file (it's showing its age) does the recursive add trick: == @ECHO OFF SETLOCAL REM Set up a string that specifies all files we want to check in SET cvs_add_list=*.cpp,*.c,*.pl,*.html,*.xml,*.txt,*.java,*.pm :parse_options if NOT %1==/? goto add_tree_head ECHO Adds a directory tree of files to CVS ECHO. ECHO ADD_TREE [directory] ECHO. ECHO If directory is passed, then that directory will be used as ECHO the root directory for the add operation - that directory ECHO and all sub-directories will be added. ECHO. ECHO Files are added according to the filter stored in the environment ECHO variable ADD_TREE_FILTER. If this is unset, the default value of ECHO %cvs_add_list% ECHO is used... ECHO. ECHO Files are added in each sub-directory. ECHO There is no way (today!) to specify exception files or exception directories. ECHO. ECHO Author: John Minnihan ECHO Author: Nick Furness GOTO :EOF :add_tree_head set head_dir= %1 IF NOT DEFINED head_dir echo Adding subtree only... IF NOT DEFINED head_dir goto add_subtree IF NOT EXIST %1 @ECHO Bad File: %1 IF NOT EXIST %1 GOTO :EOF cvs add %1 CD %1 goto add_remainder_of_subtree :add_subtree @CD %1 :add_remainder_of_subtree ECHO. ECHO. ECHO. CD ECHO * ECHO Adding directories... ECHO * FOR /D %%i in (*) DO IF /I NOT %%i==CVS cvs add %%i ECHO * IF DEFINED add_tree_filter set cvs_add_list=%add_tree_filter% REM Note that because the cvs_add_list might not only contain REM wildcard search expressions, we could attempt to add a file REM that isn't there. Silly, but true. So we'll check. ECHO Adding files... ECHO * FOR %%i IN (%cvs_add_list%) DO IF EXIST %%i cvs add %%i ECHO * REM And recurse for all the directories below... FOR /D %%i IN (*) DO IF /I NOT %%i==CVS call :add_subtree %%i CD .. GOTO :EOF ENDLOCAL == [EMAIL PROTECTED] wrote: hi! i would like to rename a directory (containing tons of subdirs and files) in my checkout and have that change applied to the repository. can i simply rename the dir; check it in (is there a recursive cvs add by the way?) and remove the dir in the repository (how? reqursively?) thanks, alex -- Alexander Welti, [EMAIL PROTECTED], A-6900 Bregenz -- John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
[ On Wednesday, September 19, 2001 at 18:39:19 (+0200), Alexander Welti wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs i received a really cool trick for my problem: go to the repository directly (have a backup copy) rename the desired directory; do a fresh checkout and everything works fine; That stupid hack will destroy any possibility of retrieving past revisions. It will also disrupt current working directories somewhat. The correct procedure (as documented in the manual) is to: 1. create the new directory 2. move all the files from the old directory to the new one 3. cvs rm * in the old directory 4. cvs add newdir 5. cd newdir; cvs add * 6. cvs commit at the root of the working directory and give a commit message that identifies exactly what you've done. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
--- Forwarded mail from Greg Woods: [ On Wednesday, September 19, 2001 at 18:39:19 (+0200), Alexander Welti wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs i received a really cool trick for my problem: go to the repository directly (have a backup copy) rename the desired directory; do a fresh checkout and everything works fine; That stupid hack will destroy any possibility of retrieving past revisions. It will also disrupt current working directories somewhat. The correct procedure (as documented in the manual) is to: 1. create the new directory 2. move all the files from the old directory to the new one 3. cvs rm * in the old directory 4. cvs add newdir 5. cd newdir; cvs add * 6. cvs commit at the root of the working directory and give a commit message that identifies exactly what you've done. 'Course, this procedure makes it harder to gather the entire version history of any file together into one place (you need to check out a new sandbox for every reorg to see it all), and it's harder to merge between branches if the contributor branch didn't have this procedure done at the same time as the destination branch. Another way to handle some of these cases is replicate the RCS files in the repository (and delete version tags), but that method has its own problems. Still another way is to write a new module and hack in the new location of the renamed directories. That solves the problems of both methods above, but adds its own set. For example, all users of the new module must perform a fresh checkout, plus you must track multiple modules for a single product. It's up to you to decide which set of problems you'd rather live with. See the manual for still more on the topic. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
[ On Wednesday, September 19, 2001 at 19:30:19 (-0700), Paul Sander wrote: ] Subject: Re: renaming a directory in the checkout / recursive add and commit for all subdirs 'Course, this procedure makes it harder to gather the entire version history of any file together into one place (you need to check out a new sandbox for every reorg to see it all) No, you don't have to check out a new sandbox. All the commit comment logs and previous revision deltas, old releases, etc. are all immediately and completely accessible, even without ANY working directory. , and it's harder to merge between branches if the contributor branch didn't have this procedure done at the same time as the destination branch. Huh? Never been a problem for me (and yes, I've done it multiple times). I suppose if someone tried to do a merge without knowing what had happened they might be in for a bit of a surprise, but provided the commit comments are meaningful enough they should be able to figure out what to do quickly enough. Another way to handle some of these cases is replicate the RCS files in the repository (and delete version tags), but that method has its own problems. Yup. The problems are almost as serious, and potentially even more serious if you've got other potential clashes with other dead files in the destination directory. Never replicate files in the repo and never make any links (hard or symlinks) in the repo! Still another way is to write a new module and hack in the new location of the renamed directories. That solves the problems of both methods above, but adds its own set. For example, all users of the new module must perform a fresh checkout, plus you must track multiple modules for a single product. Yes, that works well enough in a few cases, but generally it simply migrates the problem to a place where CVS has no good support tracking release relationships (i.e. to the modules file). It also relies on complex features of the `modules' feature which may not be stable and which are known not to behave identically on client-server and local checkouts. It really is best to keep everything all in the managed files themselves, and to do the procedure as I outlined it (which is basically the same procedure to use even if you're renaming one file within the same directory -- it's always just an add and a remove). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
renaming a directory in the checkout / recursive add and commit for all subdirs
hi! i would like to rename a directory (containing tons of subdirs and files) in my checkout and have that change applied to the repository. can i simply rename the dir; check it in (is there a recursive cvs add by the way?) and remove the dir in the repository (how? reqursively?) thanks, alex -- Alexander Welti, [EMAIL PROTECTED], A-6900 Bregenz ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
This silly little batch file (it's showing its age) does the recursive add trick: == @ECHO OFF SETLOCAL REM Set up a string that specifies all files we want to check in SET cvs_add_list=*.cpp,*.c,*.pl,*.html,*.xml,*.txt,*.java,*.pm :parse_options if NOT %1==/? goto add_tree_head ECHO Adds a directory tree of files to CVS ECHO. ECHO ADD_TREE [directory] ECHO. ECHO If directory is passed, then that directory will be used as ECHO the root directory for the add operation - that directory ECHO and all sub-directories will be added. ECHO. ECHO Files are added according to the filter stored in the environment ECHO variable ADD_TREE_FILTER. If this is unset, the default value of ECHO %cvs_add_list% ECHO is used... ECHO. ECHO Files are added in each sub-directory. ECHO There is no way (today!) to specify exception files or exception directories. ECHO. ECHO Author: John Minnihan ECHO Author: Nick Furness GOTO :EOF :add_tree_head set head_dir= %1 IF NOT DEFINED head_dir echo Adding subtree only... IF NOT DEFINED head_dir goto add_subtree IF NOT EXIST %1 @ECHO Bad File: %1 IF NOT EXIST %1 GOTO :EOF cvs add %1 CD %1 goto add_remainder_of_subtree :add_subtree @CD %1 :add_remainder_of_subtree ECHO. ECHO. ECHO. CD ECHO * ECHO Adding directories... ECHO * FOR /D %%i in (*) DO IF /I NOT %%i==CVS cvs add %%i ECHO * IF DEFINED add_tree_filter set cvs_add_list=%add_tree_filter% REM Note that because the cvs_add_list might not only contain REM wildcard search expressions, we could attempt to add a file REM that isn't there. Silly, but true. So we'll check. ECHO Adding files... ECHO * FOR %%i IN (%cvs_add_list%) DO IF EXIST %%i cvs add %%i ECHO * REM And recurse for all the directories below... FOR /D %%i IN (*) DO IF /I NOT %%i==CVS call :add_subtree %%i CD .. GOTO :EOF ENDLOCAL == [EMAIL PROTECTED] wrote: hi! i would like to rename a directory (containing tons of subdirs and files) in my checkout and have that change applied to the repository. can i simply rename the dir; check it in (is there a recursive cvs add by the way?) and remove the dir in the repository (how? reqursively?) thanks, alex -- Alexander Welti, [EMAIL PROTECTED], A-6900 Bregenz -- John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
