Re: Is there a safe way to do this kind of offline CVS management?
Doug Lee [EMAIL PROTECTED] wrote: Now for why... I write scripts for a screen-reading program called JAWS For Windows (JAWS stands for Job Access With Speech). JAWS scripts must all exist and run in a specific directory, say c:\jaws510\settings\enu. JAWS scripts are named after the applications to which they apply; thus, a script for WordPad will be named WordPad.jss (source code; the compiled version is WordPad.jsb, and there are other associated WordPad.* files as well). Every script for every application that needs special handling goes in the same directory. This is how it comes to pass that I often have multiple simultaneous projects in the same directory with no overlapping file names. I see. Well, allow me to pontificate a little. Your files are scripts and require no compilation, so you make the common mistake of confusing the *source tree* of your project (your scripts) with the *installed version* of your project (your scripts in jaws510\settings\enu with all their other script friends). The source tree goes into CVS, the installed copy doesn't. You should be doing a make install or some such to install your files... ... except that it sucks, because you can't even *test* your scripts without installing them. Which is why the above qualifies as pontification. Bottom line: JAWS is not nice, and there is nothing you can do about it. Or does JAWS understand shell links (aka Windows shortcuts) ? If yes, you could plant shortcuts from the installation directory to your CVS sandbox. Is there a tool to plant shortcuts programmatically? One other thing: are you the only one involved that uses CVS? if so I guess your approach is okay, but your initial post said something about telling everyone else to stop committing to the trunk while you were away. That negates the C in CVS, which is a shame. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management ?
On Mon, Apr 04, 2005 at 09:44:21AM -0400, Jim.Hyslop wrote: In your first message, the part Tell everyone that they should not modify the central tree really scares (and annoys) me. Generally, the only operations where you should tell people not to check things in are maintenance operations that affect the repository directly. Forgive me here please, but I understand neither what scares and annoys you, nor what you suggest. I tell people not to check in because I have the active part of the tree off site at that time. I could (and probably should) lock it somehow, but I don't want to disable READ access to it, because others may want to see it. But while I'm working directly with the client, it makes little sense for anyone else off site to check into that tree anyway, so there's never been a problem there. For your thousand files in a single directory issue, you could use the -d option in the CVS/modules file to specify that the project should be checked out into a directory named enu. That would eliminate you having to use the -d option each time you check out a project. The modules file might look something like: wordpad -s dev -d enu path/in/repository True, but we do sometimes check out elsewhere; for instance, I'm trying to set up a build system that checks out a fresh copy from which to build an installer. For now though, whenever I make a release, I often do check out outside of settings\enu. For your basic procedures, I would suggest something like this: - apply a tag to the files you're going to take on-site - 'CVS export' those files - On-site, use 'cvs import' to import them to the local repository. - modify, check-in, etc. to your heart's content - when done, take a copy of the modified local repository files (*,v) back to your office - write or find a script or tool that will pull out the changes you've done on-site, and apply them to the local repository, on a branch created from the tag in step (1) - merge changes from the branch to the head On subsequent visits, you can re-import the latest version of the repository, and merge any changes made locally. A viable alternative indeed. Again though, since I don't expect local (not at client site) commits while I'm at the client site, I don't think I should need a branch for each visit. I do tag at both ends of a site visit though. Your approach does allow off-site modifications without collision, which I will keep in mind. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com Pray devoutly, but hammer stoutly. --Sir William G. Benham ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Is there a safe way to do this kind of offline CVS management ?
Doug Lee wrote: Forgive me here please, but I understand neither what scares and annoys you, nor what you suggest. The fact that you are relying on others to remember not to modify the repository scares me. The fact that you are telling people not to modify the repository annoys me. Some of our developers used to send out emails saying Don't modify the repository, I'm about to [whatever]. As I said in my earlier email, this is very annoying, because the C in CVS stands for Concurrent - if you have to tell everybody to stay out, that's not very concurrent :=). (Side note: I managed to drill into everyone's head the usefulness of tags for every situation where they previously thought they had to protect the repository from changes.) But while I'm working directly with the client, it makes little sense for anyone else off site to check into that tree anyway, so there's never been a problem there. Yet :=) Seriously, though, if you are the only person who modifies the files, then it may not be such a big deal. If it does become a big deal, there are ways to make sections of the repository read-only of course (the cvs_acls script comes to mind, for example). A viable alternative indeed. Again though, since I don't expect local (not at client site) commits while I'm at the client site, I don't think I should need a branch for each visit. Well, on the off chance that someone does modify something while you're out, then I figured it would be easier to merge any changes if your on-site work was in a branch. A script that can handle that merging would be more complex than one that just plunks everything into a fresh branch, then does a single merge and exits, ready for you to resolve and check in any conflicts. Also, creating a branch has another advantage, in that you can keep track of which changes were done in the office, and which were done on-site. You never know when you might want or need that kind of information. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Is there a safe way to do this kind of offline CVS management ?
Catching up a little here. Boy, these conversations can move quickly on weekends! In your first message, the part Tell everyone that they should not modify the central tree really scares (and annoys) me. Generally, the only operations where you should tell people not to check things in are maintenance operations that affect the repository directly. For your thousand files in a single directory issue, you could use the -d option in the CVS/modules file to specify that the project should be checked out into a directory named enu. That would eliminate you having to use the -d option each time you check out a project. The modules file might look something like: wordpad -s dev -d enu path/in/repository For your basic procedures, I would suggest something like this: - apply a tag to the files you're going to take on-site - 'CVS export' those files - On-site, use 'cvs import' to import them to the local repository. - modify, check-in, etc. to your heart's content - when done, take a copy of the modified local repository files (*,v) back to your office - write or find a script or tool that will pull out the changes you've done on-site, and apply them to the local repository, on a branch created from the tag in step (1) - merge changes from the branch to the head On subsequent visits, you can re-import the latest version of the repository, and merge any changes made locally. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
On Mon, Apr 04, 2005 at 01:57:22AM +, Pierre Asselin wrote: Doug Lee [EMAIL PROTECTED] wrote: Now for why... I write scripts for a screen-reading program called JAWS For Windows (JAWS stands for Job Access With Speech). JAWS scripts must all exist and run in a specific directory, say c:\jaws510\settings\enu. JAWS scripts are named after the applications to which they apply; thus, a script for WordPad will be named WordPad.jss (source code; the compiled version is WordPad.jsb, and there are other associated WordPad.* files as well). Every script for every application that needs special handling goes in the same directory. This is how it comes to pass that I often have multiple simultaneous projects in the same directory with no overlapping file names. I see. Well, allow me to pontificate a little. Your files are scripts and require no compilation, so you make the common mistake Just for complete accuracy: They are indeed compiled, but both source and binary reside in the same place. The rest of your message is accurate, though I hesitate to say JAWS is not nice; for the situation being solved by JAWS, it makes sense to me. In the newest JAWS version, scripts (source and binary) go under a massively long but more modern path like C:\Documents and Settings\userName\Application Data\Freedom Scientific\JAWS\6.0\Settings\enu ... but the problem is still the same for CVS management. of confusing the *source tree* of your project (your scripts) with the *installed version* of your project (your scripts in jaws510\settings\enu with all their other script friends). The source tree goes into CVS, the installed copy doesn't. You should be doing a make install or some such to install your files... ... except that it sucks, because you can't even *test* your scripts without installing them. Which is why the above qualifies as pontification. Bottom line: JAWS is not nice, and there is nothing you can do about it. Doesn't stop me from trying. :-) Seriously though, CVS just happens to be a WONDERFUL assistant with this because of its ability to track which of the many settings\enu files matter to a project. It also helps me catch modifications to configuration files that I might otherwise make and miss accidentally: app.jcf files are text config files, so if I include them in a project on site, at the end I can capture the changes I had to make there just as easily as I capture code. The original problem I set out to address here though was how to move repo subtrees around without all the case-change problems this currently can cause. As I think I've accidentally made more of an education about JAWS than a discussion of that question here though, I think I'll consider the matter closed unless someone has a brainstorm. :-) Or does JAWS understand shell links (aka Windows shortcuts) ? If yes, you could plant shortcuts from the installation directory to your CVS sandbox. Is there a tool to plant shortcuts programmatically? I don't think JAWS can compile an app.lnk that points to c:\cvs\proj\app.jss, but even greater a problem, app.jss tends to come with app.jsd, and app.lnk can't point to both at once... Nice idea though; it hadn't occurred to me. One other thing: are you the only one involved that uses CVS? if so I guess your approach is okay, but your initial post said something about telling everyone else to stop committing to the trunk while you were away. That negates the C in CVS, which is a shame. I'm not the only CVS user here (though I'm sorta the one that started it here), but I've never had a case where one person was at a client site committing and someone else was in the office committing to the same project. (And I hear Jim's Yet echoing after me...) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com You must let me try, for a true soldier does not admit defeat before the battle. --Helen Keller (in a letter to the president of Radcliffe College) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
On Sun, Apr 03, 2005 at 12:29:48AM -0500, Russ Sherk wrote: Doug Lee [EMAIL PROTECTED] wrote: This process has worked fine except for the occasional issue with a file being renamed in the repo by something to the same name with different letter casing, my best solution to which has been a little hand-editing of CVS/Entries files in sandboxes (despite many remonstrances against this in a recent thread on this list). Regarding case changes of filenames. What version of windows are you using when the filenames change case? What filesystem is on the thumb drive? I use Win98 and Win XP. Both read the thumb drive, and I never changed the format of the thumb. Not sure what OS one would say is on the thumb drive though. Win98 will sometimes change filenames but NT/2k(3)/XP should not. If it is the latter, I would suggest that it is an application that modifies the filename, not the OS. Windows 98 however, does like to change filenames (FILE.TXT becomes File.txt). There is a checkbox in Explorer-View-Allow All Uppercase file names. I think it's a mixture, but yes, I'm sure an app is to blame sometimes. I don't know what on earth is case-changing directory names though; that's sure inconvenient when the host OS for the repo is a Unix variant... -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com No one alive is beyond hope; every second of life is a chance. (08/29/02) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
On Sun, Apr 03, 2005 at 04:18:48AM +, Pierre Asselin wrote: Doug Lee [EMAIL PROTECTED] wrote: I use CVS to manage a number of projects. When possible, I use a central repository and link to it either locally or through a tunnel. But sometimes I have to work on a CVS project at a location that has no Internet connectivity. For that, I've routinely carried repository trees around as follows: [ snip ] I check out a sandbox on a laptop and tag it before I leave. I take the laptop with me and work without the benefit of CVS (but see below). When I return I create a branch off the departure tag and update my modified sandbox to it (vacuous update, the just-created branch is empty and there is nothing to merge into the sandbox). I commit the modifications on the branch. I return to the trunk (cvs update -A) and perform a normal branch merge. I can work without CVS per se, but I'm really addicted to the safety net of revision control, so I use RCS behind CVS' back. mkdir RCS ci -l some_file_I_want_to_hack ... hack ... ci -l some_file_I_want_to_hack ... When I return, the RCS subdirectories are skipped silently because they are in the default .cvsignore . All I have to do is commit by modified sandbox to a branch as outlined above. All the modifications made on the trip are committed as a single change without the intermediate history, but this is usually not a serious drawback. I very much prefer having the off-site history preserved in the main repo, for various reasons. I'll have to think through how important that really is though. Someone, I forgot who and when, posted a gutsy move where a sandbox coexists between two CVS repositories. 1. Commit before you leave. 2. Move all CVS subdirs to something like .CVS The cheched-out tree is no longer a CVS sandbox ! 3. Import into a local repository, created with cvs init if necessary. 4. Check out from the local repository. The resulting sandbox has its CVS subdirectories but it also has .CVS subdirectories from the import, with the metadata of the original repository. 5. Hack normally off the local repository. 6. Commit before plugging back into the main network. 7. Run a script to swap every CVS with .CVS. What was an up-to-date sandbox relative to the local repository is now a modified sandbox relative to the central repository, with extra .CVS subdirectories. (Do not cvs-add these to the central repository.) 8. Do your cvs update and fix the conflicts, then commit. Once again the entire modification set ends up committed as a unit. You could even swap CVS--.CVS multiple times and alternate between two repositories that way. I've done stuff like that, but perhaps for a more gutsy reason even: having one physical directory contain multiple sandboxes for different projects. The reason I do that would take some explaining, but it's very common for me to have multiple projects in one directory in which no two of the projects share a file. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com All these years, the people said, 'He's acting like a kid.' He did not know he could not fly, so he did. --Guy Clark, The Cape (Dublin Blues) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
Hello Doug, * On Sun, Apr 03, 2005 at 04:13:24AM -0400 Doug Lee wrote: I very much prefer having the off-site history preserved in the main repo, for various reasons. I'll have to think through how important that really is though. Another option I use many times: Before going away from my CVS server, I checkout a sandbox (on an own branch) on which I want to work, in a directory dir/. After this, I copy dir1/ to another directory, for example, dir.1/. Now, whenever you want to check in something, copy dir/ to dir.2/, dir.3/, dir.4/, and so on. Furthermore, write the changelog you would want to apply into a file with a speaking name, for example, changelog.dir.2, changelog.dir.3, and-so-on. When you come back home, do the following: - go to dir.2, commit and use the changelog file changelog.dir.2 - go to dir.3, use cvs up, commit and use the changelog file changelog.dir.3 - go to dir.X, use cvs up, commit and use the changelog file changelog.dir.X This way, you preserve all the history (in a branch, but at least, you have it). This way, there is no need to fiddle with the CVS repository itself. Another option, which involves some manual steps but allows you to even ommit the branch: Do as before, that is, generate dir.1, dir.2, dir.3, and so on. After coming home, diff against the directories (diff -urN dir.1 dir.2 1-2.diff, diff -urN dir.2 dir.3 2-3.diff) and put the diffs into files. Now, go to dir.1 (the original copy), cvs up, and apply the diffs to the sandbox (patch 1-2.diff), commit and use changelog.dir.2. Now, apply the next diff, commit and use changelog.dir.3. As long as there are no conflicts applying the patches, this works as expected I hope I did not forget any step. Regards, 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
Re: Is there a safe way to do this kind of offline CVS management?
Ok, this will probably seem odd to many on this list, but here goes... On Sun, Apr 03, 2005 at 11:31:01AM +0200, Spiro Trikaliotis wrote: Hello Doug, * On Sun, Apr 03, 2005 at 04:13:24AM -0400 Doug Lee wrote: I very much prefer having the off-site history preserved in the main repo, for various reasons. I'll have to think through how important that really is though. Another option I use many times: Before going away from my CVS server, I checkout a sandbox (on an own branch) on which I want to work, in a directory dir/. After this, I copy dir1/ to another directory, for example, dir.1/. Now, whenever you want to check in something, copy dir/ to dir.2/, dir.3/, dir.4/, and so on. Furthermore, write the changelog you would want to apply into a file with a speaking name, for example, changelog.dir.2, changelog.dir.3, and-so-on. When you come back home, do the following: - go to dir.2, commit and use the changelog file changelog.dir.2 - go to dir.3, use cvs up, commit and use the changelog file changelog.dir.3 - go to dir.X, use cvs up, commit and use the changelog file changelog.dir.X This way, you preserve all the history (in a branch, but at least, you have it). This way, there is no need to fiddle with the CVS repository itself. Another option, which involves some manual steps but allows you to even ommit the branch: Do as before, that is, generate dir.1, dir.2, dir.3, and so on. After coming home, diff against the directories (diff -urN dir.1 dir.2 1-2.diff, diff -urN dir.2 dir.3 2-3.diff) and put the diffs into files. Now, go to dir.1 (the original copy), cvs up, and apply the diffs to the sandbox (patch 1-2.diff), commit and use changelog.dir.2. Now, apply the next diff, commit and use changelog.dir.3. As long as there are no conflicts applying the patches, this works as expected Summary of what I'm about to explain: Most of my projects are actually checked out in a directory with literally up to a thousand files that are not part of the project itself. I'll explain why in a minute, lest I get a lot of cut that out! comments. :-) But the upshot is that the above ideas would be rather complex. I actually use CVS on work sites to keep track of exactly which files are and are not part of a given project. For that matter, at home and in my office, I very often have several active CVS sandboxes in the same directory; I just rename the CVS directory for all but the project I'm working on to something else. Obviously no two projects share a file though. Now for why... I write scripts for a screen-reading program called JAWS For Windows (JAWS stands for Job Access With Speech). JAWS scripts must all exist and run in a specific directory, say c:\jaws510\settings\enu. JAWS scripts are named after the applications to which they apply; thus, a script for WordPad will be named WordPad.jss (source code; the compiled version is WordPad.jsb, and there are other associated WordPad.* files as well). Every script for every application that needs special handling goes in the same directory. This is how it comes to pass that I often have multiple simultaneous projects in the same directory with no overlapping file names. Now obviously I could (and sometimes do) create a separate sandbox, copy files back to the live directory as needed, etc. But JAWS comes with a Script Manager--sort of a simple IDE for scripting--and it expects all scripts to be in that same directory... so it's far easier to edit them there than anywhere else. So my typical routine is like this for a new project: Go to a site, make a blank project by an mkdir under CVSROOT, then check out the blank project like this: c: cd \jaws510\settings cvs co -d enu projName cd enu (leave the DOS box open in that directory) Then as I create/modify files, I add them from the DOS box I left active and in the live directory, c:\jaws510\settings\enu in this case: cvs add app.jss app.jsd app.jkm app.jcf cvs commit -m First recorded version. I thus build up a repository from a sandbox that is literally the live code, committing at the end of a day or when I make a major enhancement or fix, etc. When I'm done, I take the new repo back and plug it into the central master repo for all projects. Next time I visit that site, I take the repo with me from the office and use it to, among other things, detect any changes made since I last left. I plug it in on site like this: Carry it there by zip, unzip into a CVSROOT, make a fresh checkout somewhere else NOT under (in our example) c:\jaws510\settings\enu, then move the resulting CVS directory under that sandbox to be under c:\jaws510\settings\enu. I then run `cvs diff' to detect changes, then make any necessary commits and start from there and work as I described earlier. The RCS idea recommended earlier by Pierre would help here I suppose, but it still seems more cumbersome than
Is there a safe way to do this kind of offline CVS management?
I use CVS to manage a number of projects. When possible, I use a central repository and link to it either locally or through a tunnel. But sometimes I have to work on a CVS project at a location that has no Internet connectivity. For that, I've routinely carried repository trees around as follows: 1. Tell everyone that they should not modify the central tree, then check out the current HEAD from the tree of interest somewhere at the office so I can use it as a sanity check when I get back. 2. Zip up the tree, take the zip to the work site, and unpack it there into a freshly initialized CVS tree. 3. Work as usual, checking out, modifying files, and committing as needed. 4. Zip up the on-site tree, bring it back to the central server, and use the zip to replace the original tree. 5. Do a cvs update in the sandbox I created in step 1 as a sanity check. This process has worked fine except for the occasional issue with a file being renamed in the repo by something to the same name with different letter casing, my best solution to which has been a little hand-editing of CVS/Entries files in sandboxes (despite many remonstrances against this in a recent thread on this list). This week though, I decided to extend the concept a bit, and I ported a whole raft of things from the central repository over to a thumb drive, then worked on things while on the road. I planned to use `diff' on returning home to detect changed repo files, then drop in the on-the-road versions as needed. I was thwarted, though, by a whole mess of directories whose names had magically become upper-cased on the thumb drive. As a result, what should have taken me some 20 minutes max took hours to straighten out. I know straight CVS does not have support for offline commits etc. and that svk does, but moving from CVS to Subversion or Superversion at this point would be a pretty major undertaking. I prefer a saner method of doing what I do now, within CVS with the inclusion of add-on software if necessary. My ideal situation would be the ability to check out a repo tree and leave it locked in the central repo if necessary while I'm gone, make my commits etc., then easily check in the modified offline repo tree on returning, without having all this trouble with letter casing in file and directory names. The ability to allow in-office commits simultaneous with out-of-office offline commits would be wonderful, but I don't know how practical that is. A couple details possibly worthy of note: The central server is a FreeBSD box running CVS 1.11.17. The sandboxes are typically created on Windows machines using CVS 1.11.9. (If it will help, I can upgrade the Windows machines to 1.11.17.) I do occasionally make checkouts under FreeBSD or Cygwin, but I never handle a given sandbox with a different OS than the one that created it. I've seen discussion of a commercial CVS replicator on this list but didn't pay close attention. A low-cost commercial package is possible, but an expensive one, or one that is priced per user, is not likely to make it into the picture right now. I doubt a simple use of `rsync' would be sufficient given the letter casing issues I keep hitting. It actually seems like I'm really looking for a CVS for CVS repositories, where my thumb drive or on-site repo copy is a sandbox and the central repo itself is another sandbox that remains always checked out; but the idea of merging changes to a repo file sort of boggles my mind a bit. :-) All advice welcome. Thanks much. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com Nearly all men can stand adversity, but if you want to test a man's character, give him power. -Abraham Lincoln ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
Doug Lee [EMAIL PROTECTED] wrote: I use CVS to manage a number of projects. When possible, I use a central repository and link to it either locally or through a tunnel. But sometimes I have to work on a CVS project at a location that has no Internet connectivity. For that, I've routinely carried repository trees around as follows: [ snip ] I check out a sandbox on a laptop and tag it before I leave. I take the laptop with me and work without the benefit of CVS (but see below). When I return I create a branch off the departure tag and update my modified sandbox to it (vacuous update, the just-created branch is empty and there is nothing to merge into the sandbox). I commit the modifications on the branch. I return to the trunk (cvs update -A) and perform a normal branch merge. I can work without CVS per se, but I'm really addicted to the safety net of revision control, so I use RCS behind CVS' back. mkdir RCS ci -l some_file_I_want_to_hack ... hack ... ci -l some_file_I_want_to_hack ... When I return, the RCS subdirectories are skipped silently because they are in the default .cvsignore . All I have to do is commit by modified sandbox to a branch as outlined above. All the modifications made on the trip are committed as a single change without the intermediate history, but this is usually not a serious drawback. Someone, I forgot who and when, posted a gutsy move where a sandbox coexists between two CVS repositories. 1. Commit before you leave. 2. Move all CVS subdirs to something like .CVS The cheched-out tree is no longer a CVS sandbox ! 3. Import into a local repository, created with cvs init if necessary. 4. Check out from the local repository. The resulting sandbox has its CVS subdirectories but it also has .CVS subdirectories from the import, with the metadata of the original repository. 5. Hack normally off the local repository. 6. Commit before plugging back into the main network. 7. Run a script to swap every CVS with .CVS. What was an up-to-date sandbox relative to the local repository is now a modified sandbox relative to the central repository, with extra .CVS subdirectories. (Do not cvs-add these to the central repository.) 8. Do your cvs update and fix the conflicts, then commit. Once again the entire modification set ends up committed as a unit. You could even swap CVS--.CVS multiple times and alternate between two repositories that way. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
Doug Lee [EMAIL PROTECTED] wrote: This process has worked fine except for the occasional issue with a file being renamed in the repo by something to the same name with different letter casing, my best solution to which has been a little hand-editing of CVS/Entries files in sandboxes (despite many remonstrances against this in a recent thread on this list). Regarding case changes of filenames. What version of windows are you using when the filenames change case? What filesystem is on the thumb drive? Win98 will sometimes change filenames but NT/2k(3)/XP should not. If it is the latter, I would suggest that it is an application that modifies the filename, not the OS. Windows 98 however, does like to change filenames (FILE.TXT becomes File.txt). There is a checkbox in Explorer-View-Allow All Uppercase file names. Not sure if that is your problem tho. Regards, --Russ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
