efficiency over NFS
Alexander Belchenko
bialix at ukr.net
Thu Mar 6 22:05:46 GMT 2008
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
>
>
More information about the bazaar
mailing list