info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: renaming under CVS


From: Paul Sander
Subject: Re: renaming under CVS
Date: Mon, 25 Feb 2002 23:35:52 -0800

>--- Forwarded mail from address@hidden

>--- Paul Sander <address@hidden> wrote:
>> >--- Forwarded mail from address@hidden
>> >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 address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]