efficiency over NFS

[Alexander Belchenko]

Talden пишет:
> On Fri, Mar 7, 2008 at 10:21 AM, Mohit Aron <extproxy at gmail.com> wrote:
>>
>>
>>
>>
>>> My view on the issue is that there is a reason very few vcs systems'
>> default behavior is file locking. The ones that have edit/lock are generally
>> designed for giant repositories such ms windows 100's of branches at 15-25gb
>> for lightweight checkout each. Virtually every other new vcs system I have
>> seen does not encourage 'edit' because of general dislike of the workflow it
>> requires
>>
>> Yes, and the proposed 'edit' command has nothing to do with locking at all.
>> I DO NOT want the file to be locked. Two developers should be free to 'edit'
>> the same file in their workspaces. All 'edit' should do is record in the
>> repository that this file is being modified so that the filesystem  doesn't
>> need to be consulted. That's it.
> 
> Aha so not really like the CVS edit, Subversion lock, VSS or clearcase
> edit-locks at all.
> 
> So really we'd need at least the following changes...
> 
> 1. A flag in the branch/checkout options that tells Bazaar we're only
> interested in scheduled changes by default

bzr uses approach with file existence for flags. So I guess something like
.bzr/checkout/edits file could be enough. Each line in such file could be
exact filename or glob pattern. So '**/*' should means: edit --all!

> 2. An option on status to ignore the flag in (1).  That is, sometimes
> we need to look for all changes.

and diff command too. and may be ls for consistency.

> 3. An edit command that adds paths to a scheduled list (and 'add',
> 'remove', 'move' should add paths here too).

merge, revert should change such file too.

> 4. An option on commit to commit scheduled changes (or perhaps this
> could be a default if the flag in (1) is present).
> 
> Does this make more sense for what you're after?
> 
> --
> Talden
> 
>