[Top][All Lists]
[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
- Re: CVS Update Behaviour, (continued)
- Re: CVS Update Behaviour, Noel Yap, 2002/02/23
- Re: CVS Update Behaviour, Greg A. Woods, 2002/02/24
- Re: renaming under CVS, Noel Yap, 2002/02/24
- Re: renaming under CVS, Paul Sander, 2002/02/25
- Re: renaming under CVS, Noel Yap, 2002/02/25
- Re: renaming under CVS, Mark, 2002/02/25
- Re: renaming under CVS, Greg A. Woods, 2002/02/25
- Re: renaming under CVS,
Paul Sander <=
- Re: renaming under CVS, Greg A. Woods, 2002/02/25
- Re: renaming under CVS, Paul Sander, 2002/02/26
- Re: renaming under CVS, Noel Yap, 2002/02/26
- Re: renaming under CVS, Greg A. Woods, 2002/02/26
- Re: renaming under CVS, Noel Yap, 2002/02/26
- Re: renaming under CVS, Greg A. Woods, 2002/02/27
- Re: renaming under CVS, Noel Yap, 2002/02/27
- Re: renaming under CVS, Greg A. Woods, 2002/02/27
- Re: renaming under CVS, Noel Yap, 2002/02/27
- Re: renaming under CVS, Greg A. Woods, 2002/02/27