Re: Locking binary files

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

 



On Tue, 23 Sep 2008, Mario Pareja wrote:

> > So it's a communication issue then.
> 
> Yes, but I think the communication of this information needs to happen
> as part of a developers normal work-flow rather than requiring them to
> remember to check an external system.
> 
> > The way I understand locks in svn
> > and cvs is that they also only bother you when you want to check in the
> > file you've just recently modified, or if multiple people want to lock
> > the same file at the same time.
> 
> The SVN client will make locked files read-only until a lock is
> obtained for them.  This helps "remind" you that a lock should be
> obtained before editing such a file. Requiring the developer to obtain
> a lock ensures that nobody else is editing the file and prevents
> wasted work.  Upon commit, the file is marked as unlocked and the
> local file is once again read-only.

I think the right tool on the git side is actually a "smudge/clean" 
script. When you check something out, git converts it from the 
repository-stored form to a working tree form using a script (if there is 
one configured); this could check whether you've got the appropriate lock, 
and make the file unwritable if you don't. Then you have a script that 
gets or releases a lock and sets any write bits on files already checked 
out appropriately. There could also be locking-server magic to detect that 
you've pushed a change and release the lock, telling you so that it makes 
your file unwritable, but that's optional.

(Side note: consider version-specific logos; which lock you need depends 
on which version you're working on, and you may want to pick up locks for 
multiple versions and make changes to each logo, switching between the 
branches, and make sure you can get all the locks before you start 
working on any of the files, despite not having any individual file 
checked out continuously in the process)

> > Note that locking would be completely advisory though, and nothing
> > would prevent people from committing changes to a locked file.
> 
> If git were to support locking then it could prevent people from
> committing without first locking.  Even if it is not supported
> directly by git - perhaps using a lock daemon - a wrapper would need
> to be written around git commit/push to prevent developers from
> committing/pushing changes that would cause binary merging conflicts.

If you've gotten to the point of committing (let alone pushing), and you 
haven't got exclusive access, git should certainly not prevent you; the 
point of the locking is to prevent people from doing work that will be 
wasted, and the work is already done at this point. It's better then to 
actually try the binary merge, which comes down to apologizing profusely 
and then somebody openning the 3 versions (theirs, the other side's, and 
the common ancestor) in their graphics program and modifying the other 
side's to include their change. It wouldn't help anything to prevent 
people from being able to get all of these versions to each other, once 
they're made. It's also helpful to have people commit what they did before 
redoing it, so that they can use it for reference in the process and won't 
lose it.

(Actually, I bet it would be not-too-hard to set up gimp for three-way 
merge of images; open the result file with "theirs" as the contents, and 
open the common ancestor and "yours" as extra layers and set the ancestor 
to negative, and make the user clean up the mess)

On the other hand, the locking server should reject your push if somebody 
else has got the lock, so that the person who editted the file without 
having the lock is the one stuck redoing things.

In any case, the fundamental idea is: (a) you want some server to favor 
people who declare their intent to change something in advance, and give 
all the work of redoing stuff to people who didn't declare their intent in 
advance; and (b) you want to prompt people to declare their intent in case 
they forget.

(a) is a pre-update hook that checks the diffstat against other people's 
locks. (b) is a smudge script that makes files you're supposed to lock and 
haven't a-w. Of course, git doesn't have the code for manipulating a 
per-user set of locks, but it shouldn't be too hard to find some project 
that just does that.

	-Daniel
*This .sig left intentionally blank*
--
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]

  Powered by Linux