Re: feature request

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

 



On 16 October 2012 22:36, Angelo Borsotti <angelo.borsotti@xxxxxxxxx> wrote:
>
> Hello,
>
> some VCS, e.g. ClearCase, allow to control the fetching of files so as
> to warn, or
> disallow parallel changes to the same files.
> As of today, there is no way to implement the same kind of workflow with
> git
> because there are no fetch hooks.
> Would it be a good idea to provide them?
>
> -Angelo Borsotti

It seems like you want to be able to lock a file for editing once
someone has 'checked-out' the file. This really only makes sense for
binary files (or files which there is no straightforward way to merge)
as otherwise you are throwing away the usefulness of git without any
gain. Git is designed so that multiple people can work on a file at
the same time. Easy merging means that collating those changes is an
easy task, and so locking a file has no use. If a file cannot be
easily merged then it does make sense to lock the file. Is this what
you need to do, or is there some other reason for wanting a lock?

In any case, locking a file is a hard thing to do right in a
distributed system, and doesn't really make sense (although it may be
useful!) When you clone a git repository you have the entire history
of the repository on your computer. What does it mean to have a locked
file? Does the file get deleted from everyone's repository every time
someone else locks it? That would seem silly. Perhaps everyone simply
can't write to that file once it has been locked - how do you impose
that restriction in a distributed system (you can't)?

Instead you can only refuse pushes that change the locked file (which
is normal - you would have to force the push for any non fast-forward
changes), and you can try to warn users that somebody else has locked
the file. This warning system might be doable in some fashion, by
using hooks to write the locked files to a text file somewhere and
checking that, however it would be near impossible to get right or
would hamstring the distributed nature of git by forcing constant
server checks.

Instead of continuing making the point here, let me point you towards
some other discussions around file locks, in particular how git
handles binary files. You should be able to find many more, but as a
starter, look at [1] and [2].

In general, I would reconsider why two users shouldn't be able to
change the same file at the same time.

Regards,

Andrew Ardill

[1] http://stackoverflow.com/questions/119444/locking-binary-files-using-git-version-control-system
[2] http://git.661346.n2.nabble.com/Lock-binairy-files-in-Git-td2422894.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]