Re: Repository directories and symlinks
Alleman, Lowell writes: > > Symlinking directories within the repository: > > 1. Will it work? Mostly. There have been reports of CVS objecting to symlinks -- whether you'll hit any of them or care that they don't work I can't say. > 2. Will I loose data? You shouldn't. (Note, however, that symlinking *files* is most definitely *NOT* safe, only directories.) -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository directories and symlinks
In article <[EMAIL PROTECTED]>, Alleman, Lowell wrote: > >I want to reorganize the directory structure of my cvs repository, but there >are still a number of sandboxes lying around and a couple of scripts which >rely on certain files being at certain locations within the repository (It's >not ideal, but it's what I have to work with.). I would like to move the >directories to where I want them, and then make symlinks connecting the old >and new locations. > >Yes, I've tried doing this with the modules file, but it just isn't flexible >enough. I either can't use the name I want or position the module under >another module, or I end up with superfluous modules names. If I'm >missing something here, let me know. > > >Symlinking directories within the repository: > >1. Will it work? Sort of. >2. Will I loose data? Probably not, but you could screw up your ability to go back to old releases if you don't know what you are doing or aren't careful. >3. What other problems can I expect? - When files move in or out of Attic directories, symlinks break. This happens when files are removed on the main trunk, or added on a branch and then commited to the main trunk. - When a file is removed (via cvs remove), then every symlink pointing to it appears removed; it's necessary to manually break the symlink before doing a cvs remove. Breaking the link meaning that the object to be removed is an actual object, and not a link, and has no links pointing at it. - Older versions of CVS didn't handle symlinks right; they did not chase the link and acquire locks in the right places. this was fixed around 1.10.3. Because of these problems, symlinks become a liability. Users cannot manage these symlinks themselves, only some person in charge of the repository. You can't have people mucking around in the repository to get their jobs done, it's just not sound CM. If you do have some links, and other people don't realy know about them, and you get run over by a bus, the above problems will eventually bite people who might lack the CVS expertise to know what to do. >4. Is there a better way? I have a client side solution called Meta-CVS. http://users.footprints.net/~kaz/mcvs.html This is alpha software, that currently runs only on GNU/Linux. Sane, robust versioning of the directory structure (and that means parallel changes with merging and conflict resolution). Plus sane file adds and removes. No changes to CVS are required, and nothing needs to be installed on the server side. On the downside, there is the current platform restriction; moreover, it can't use existing modules without conversion, for which I haven't yet written the tool. Some tools designed to work with CVS won't work with Meta-CVS, such as probably most GUI front ends like WinCVS which peek at the CVS subdirectories that don't exist under Meta-CVS. Caveats aside, I'm extremely happy with it and I'm using it already. You might not be able to use it now, but at least you have one possible light at the end of the tunnel. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Repository directories and symlinks
> -Original Message- > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, February 06, 2002 6:24 PM > To: [EMAIL PROTECTED] > Subject: Re: Repository directories and symlinks > > > >3. What other problems can I expect? > > - When files move in or out of Attic directories, symlinks break. This > happens when files are removed on the main trunk, or added on a branch > and then commited to the main trunk. > > - When a file is removed (via cvs remove), then every symlink pointing > to it appears removed; it's necessary to manually break the symlink > before doing a cvs remove. Breaking the link meaning that the object > to be removed is an actual object, and not a link, and has no links > pointing at it. > > - Older versions of CVS didn't handle symlinks right; they did not > chase the link and acquire locks in the right places. this was > fixed around 1.10.3. > Are you talking about symlinking files or symlinking directories? It sounds like your talking about symlinking files, which I am not trying to do. I'm just interested in symlinking directories. Thanks, Lowell Alleman ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository directories and symlinks
> > - Older versions of CVS didn't handle symlinks right; they did not > chase the link and acquire locks in the right places. this was > fixed around 1.10.3. I'm reasonably certain that CVS still doesn't handle symlinked files in the repository. -Larry Jones I don't need to do a better job. I need better P.R. on the job I DO. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository directories and symlinks
In article <[EMAIL PROTECTED]>, Alleman, Lowell wrote: >> >3. What other problems can I expect? >> >> - When files move in or out of Attic directories, symlinks break. This >> happens when files are removed on the main trunk, or added on a branch >> and then commited to the main trunk. >> >> - When a file is removed (via cvs remove), then every symlink pointing >> to it appears removed; it's necessary to manually break the symlink >> before doing a cvs remove. Breaking the link meaning that the object >> to be removed is an actual object, and not a link, and has no links >> pointing at it. >> >> - Older versions of CVS didn't handle symlinks right; they did not >> chase the link and acquire locks in the right places. this was >> fixed around 1.10.3. >> >Are you talking about symlinking files or symlinking directories? It sounds I was mistakenly talking about symlinking files. >like your talking about symlinking files, which I am not trying to do. I'm >just interested in symlinking directories. Right. Too bad Usenet article cancelation doesn't propagate well into lists? Ah well, at least you are forewarned about file symlinking. :) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
