>--- Forwarded mail from [EMAIL PROTECTED] >--- Paul Sander <[EMAIL PROTECTED]> wrote: >> >--- Forwarded mail from [EMAIL PROTECTED] >> >I'm starting to think about a scheme where CVS >> would >> >go through a filename mapping if the usual archive >> >file isn't found (I think this is how Meta-CVS >> works). >> > The mapped archive file would only exist if >> there's >> >been a rename or move. I don't think such a scheme >> >would _fundamentally_ break backwards >> compatibility. >> >> I've given a lot of thought to this over the past >> few years, and >> due to the way that locking is done in CVS >> (filesystem-based cookies), >> a simple mapping mechanism will drive performance >> way down if a lot of >> renaming is done. This is because (in the general >> case) the mapping >> mechanism will drive the creation of locks in many >> directories that >> are not really the focus of the user's attention. >> >> To keep it efficient enough to use, I think that the >> locking >> mechanism needs to be removed from the filesystem >> and placed into >> a process, which means losing the benefits of >> supporting local >> mode (at least until the server modes become >> multi-threaded).
>Actually, I was thinking that, in the long run, it'll >improve performance. Let's say that all filenames are >now mapped to their corresponding archive files, then >there's really need to create one lock file for the >entire module much as CC locks the entire VOB. In >fact, if backwards compatibility weren't an issue (eg >if it's a new repository), this behaviour could be the >default. Unfortunately, modules can overlap, which means that the new locking mechanism must have a granularity smaller than the module. Depending on how the mapping is done, especially if there's an attempt to preserve backward compatibility (and preserving CVS' existing directory-based locking in the repository) then you end up locking every directory that contains a ,v file that maps to a file in the user's sandbox, every time an update or commit is done. There are ways of dealing with this, of course. But think you're on the wrong track here. >I was also thinking about the above and figured that >CVS would have to check the mapping before it checked >the normal way it did things to avoid problems with >resurrections. Yes, indeed! >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
