Stefan Beller <sbeller@xxxxxxxxxx> writes:
> I could imagine a "git lock" command which looks like this:
>
> git config lock.centralServer origin
> git config lock.defaultBranch master
>
> git lock add [branch] [--] <path/to/file>
> git lock remove [branch] [--] <path/to/file>
> git lock ls [<branch>]
>
> And the way this is implemented is roughly (unoptimized, just showing
> how you would achieve this with todays command set):
> ...
> git fetch --depth=1 $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch)
> git checkout refs/locks/$(git config --get lock.centralServer)/$(git config --get lock.defaultBranch)
> switch(option) {
> case add:
> if exist <path/to/file>
> return -1
> else
> echo $(git config --get user.name) $(date) > <path/to/file>
> git add <path/to/file> && git commit "add new lock"
> fi
> case remove:
> if exist <path/to/file>
> # todo: check if the same user locked it before
> rm <path/to/file>
> else
> return -1
> fi
> case ls:
> ls -R .
> }
> git push $(git config --get lock.centralServer) refs/locks/$(git config --get lock.defaultBranch)
> git <restore working tree, branch>
>
> That said you could just manipulate the git objects directly, no need
> to check out to the working dir.
>
> The server would only need to allow pushes to a refs/locks directory and be done.
> the client side would need to have a plumbing command, so you could easily integrate
> a git locking to your application if you don't want to provide a merge driver.
I do not think that would be very useful nor even be a good starting
point, even though I think it is a good tangent to think about how
to improve the support for the centralized workflow.
You cannot afford to force clients keep polling the central server
for the refs/locks/my-branch, if you want a good "everybody relies
on central-server to coordinate" workflow experience.
And even without "file locking", once you start assuming "everybody
relies on central-server to coordinate" workflow (which is common in
corporate settings), you would be better off introducing a mechanism
to push notification from the server side to the clients to improve
support for other things, like "the client watches these branches,
doing a hanging Get or whatever, waiting for the server to notify"
anyway. The kind of notification that distributed use of Git can do
without.
And once that kind of mechanism is there, "the client is notified
not to touch these paths on this branch", "the client is notified
that it is now OK to touch these paths on this branch after
updating", etc., would be a natural addition.
I highly doubt that exchanging data via the "git fetch" and "git
push" will be a good vehicle to implement such an async notification
mechanism.
--
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