From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:24
Daniel Barkalow [off-list ref] writes:
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.
An obvious question is "how would such a script check the lock when you
are 30,000 ft above ground"; in other words, this "locking mechanism"
contradicts the very nature of distributed development theme. The best
mechanism should always be on the human side. An SCM auguments
inter-developer communication, but it is not a _substitute_ for
communication.
But if you limit the use case to an always tightly connected environment
(aka "not distributed at all"), I agree the above would be a very
reasonable approach.
Such a setup would need a separate locking infrastructure and an end user
command that grabs the lock and when successful makes the file in the work
tree read/write. The user butchers the contents after taking the lock,
saves, and then when running "git commit", probably the post-commit hook
would release any relevant locks.
All these can be left outside the scope of git, as they can be hooked into
git with the existing infrastructure. Once a BCP materializes it could be
added to contrib/ just like the "paranoid" update hook.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:24
On Tue, 23 Sep 2008, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
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.
An obvious question is "how would such a script check the lock when you
are 30,000 ft above ground"; in other words, this "locking mechanism"
contradicts the very nature of distributed development theme. The best
mechanism should always be on the human side. An SCM auguments
inter-developer communication, but it is not a _substitute_ for
communication.
If you're offline, you can't get new locks, nor release them. But it can
make reasonable decisions if it remembers what locks you got before.
On the other hand, you can just make the file writable yourself while
disconnected, and nothing bad happens to anybody else; if someone else
locks the file and starts working, they'll block your eventual push until
they push and you merge. And nothing too bad happens to you; you get stuck
redoing the change later (as a merge), but (a) you would have had to do
the work then anyway; (b) you knew you weren't protecting yourself; and
(c) at least you got to practice on the plane.
The point of the locking is just that, if you get the lock for a
particular file in a particular branch on a particular shared repository,
you can be sure you won't have to merge that file in order to push there,
and you can get this worked out in advance of having the push ready. A
secondary concern is that you might want to stop yourself from working on
certain things without this kind of reservation, but that's a local
decision.
But if you limit the use case to an always tightly connected environment
(aka "not distributed at all"), I agree the above would be a very
reasonable approach.
Such a setup would need a separate locking infrastructure and an end user
command that grabs the lock and when successful makes the file in the work
tree read/write. The user butchers the contents after taking the lock,
saves, and then when running "git commit", probably the post-commit hook
would release any relevant locks.
The lock needs to last until you push to the repository the lock is for;
otherwise you have the exclusive ability to make changes, but someone who
grabs the lock right after you release it will still be working on the
version without your change, which is what the lock is supposed to
prevent.
All these can be left outside the scope of git, as they can be hooked into
git with the existing infrastructure. Once a BCP materializes it could be
added to contrib/ just like the "paranoid" update hook.
It would be handy to link against some of git, since it will want to use
git config files and remotes and refspecs to figure out what lock to ask
for on the client side, and how to communicate with the target remote
repository, and the process of getting a lock requires checking that
you're up-to-date, and git's also got a bunch of useful code for atomic
file updates and repository-scoped filename management. But adding this
doesn't have to modify any existing behavior.
-Daniel
*This .sig left intentionally blank*
On Tue, Sep 23, 2008 at 05:13:29PM -0400, Daniel Barkalow wrote:
The lock needs to last until you push to the repository the lock is for;
otherwise you have the exclusive ability to make changes, but someone who
grabs the lock right after you release it will still be working on the
version without your change, which is what the lock is supposed to
prevent.
It still will happen if developers work on topic branches, and it is not
a rate situation with Git. Thus locking some particular path is stupid.
What you may want instead is too mark SHA-1 of this file as being edited
and later maybe as being replaced with another one. In this case, anyone
who has the access to the central information storage will get warning
about attempt to edit a file that is edited or already replaced with a
new version.
Dmitry
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:24
On Wed, 24 Sep 2008, Dmitry Potapov wrote:
On Tue, Sep 23, 2008 at 05:13:29PM -0400, Daniel Barkalow wrote:
quoted
The lock needs to last until you push to the repository the lock is for;
otherwise you have the exclusive ability to make changes, but someone who
grabs the lock right after you release it will still be working on the
version without your change, which is what the lock is supposed to
prevent.
It still will happen if developers work on topic branches, and it is not
a rate situation with Git. Thus locking some particular path is stupid.
What you may want instead is too mark SHA-1 of this file as being edited
and later maybe as being replaced with another one. In this case, anyone
who has the access to the central information storage will get warning
about attempt to edit a file that is edited or already replaced with a
new version.
No, your goal is to avoid having to do a merge in order to do a particular
push. That push is the push to the shared location. It doesn't matter if
you use topic branches, because your eventual goal is still to push to the
shared location (or, possibly, to have the project maintainer push to the
shared location with some sort of interesting delegation), so you lock the
shared location, not your topic branch.
On the other hand, it's easily possible that other people (or you) want to
fork the image, such that only some locations (either different paths in
the project or the same path in different branches) get your change and
other branches get different changes made at the same time. Of course, if
you want to change multiple things, you need to get multiple locks.
-Daniel
*This .sig left intentionally blank*
On Tue, Sep 23, 2008 at 06:29:53PM -0400, Daniel Barkalow wrote:
On Wed, 24 Sep 2008, Dmitry Potapov wrote:
quoted
It still will happen if developers work on topic branches, and it is not
a rate situation with Git. Thus locking some particular path is stupid.
What you may want instead is too mark SHA-1 of this file as being edited
and later maybe as being replaced with another one. In this case, anyone
who has the access to the central information storage will get warning
about attempt to edit a file that is edited or already replaced with a
new version.
No, your goal is to avoid having to do a merge in order to do a particular
push. That push is the push to the shared location. It doesn't matter if
you use topic branches, because your eventual goal is still to push to the
shared location (or, possibly, to have the project maintainer push to the
shared location with some sort of interesting delegation), so you lock the
shared location, not your topic branch.
What are you saying is that when I am locking some file on the current
branch, Git (or whatever script that performs this locking) should figure
out what is the original shared branch for it and lock the file there.
When you have finished to edit and push changes then the lock should be
removed if changes are pushed to this shared branch, otherwise it should
be some token of delegation to the project maintainer who is going to
push (or probably first merge, because other files may need that) to
this branch.
Maybe, it can work, but it sounds too complex to me. I believe that my
idea using SHA-1 is better. After all, what is file? It is its content.
At least, in Git, we always identify files by their content. Thus if you
lock some file, you put a lock on certain SHA-1. Now, regardless of
branches and paths, this lock can work provided that you have access to
some shared location. Of course, this lock is purely advisory, but it is
good, because you may want to ignore it in some case. For instance, you
want to created a new branch based on the current shared location and
have no plan to ever merge it back. In this case, the lock on the shared
branch should not matter to you. This is true regardless how you
implement locking, and in your scheme it will another special case.
Dmitry
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:24
On Wed, 24 Sep 2008, Dmitry Potapov wrote:
On Tue, Sep 23, 2008 at 06:29:53PM -0400, Daniel Barkalow wrote:
quoted
On Wed, 24 Sep 2008, Dmitry Potapov wrote:
quoted
It still will happen if developers work on topic branches, and it is not
a rate situation with Git. Thus locking some particular path is stupid.
What you may want instead is too mark SHA-1 of this file as being edited
and later maybe as being replaced with another one. In this case, anyone
who has the access to the central information storage will get warning
about attempt to edit a file that is edited or already replaced with a
new version.
No, your goal is to avoid having to do a merge in order to do a particular
push. That push is the push to the shared location. It doesn't matter if
you use topic branches, because your eventual goal is still to push to the
shared location (or, possibly, to have the project maintainer push to the
shared location with some sort of interesting delegation), so you lock the
shared location, not your topic branch.
What are you saying is that when I am locking some file on the current
branch, Git (or whatever script that performs this locking) should figure
out what is the original shared branch for it and lock the file there.
Or you should have to say. But "git lock <filename>" should probably
put the lock on whatever branch "git push" would push to, and similarly
for the other argument combinations that "git push" permits.
When you have finished to edit and push changes then the lock should be
removed if changes are pushed to this shared branch, otherwise it should
be some token of delegation to the project maintainer who is going to
push (or probably first merge, because other files may need that) to
this branch.
Correct.
Maybe, it can work, but it sounds too complex to me. I believe that my
idea using SHA-1 is better. After all, what is file? It is its content.
At least, in Git, we always identify files by their content.
Not at all; there are plenty of cases where what matters is the path, and
some things are relevant by virtue of the form of the filename which names
that content.
Thus if you lock some file, you put a lock on certain SHA-1. Now,
regardless of branches and paths, this lock can work provided that you
have access to some shared location. Of course, this lock is purely
advisory, but it is good, because you may want to ignore it in some
case.
In my design, the lock (on the shared repository) is not advisory; if
someone else has it, you can't push if the new commit doesn't match the
old commit for that path. (Of course, the system might let you break the
other person's lock.) I don't think locks are particularly useful if you
don't get some particular guarantee out ofhaving them (in my case, that
somebody else will have to do any merge for the file if one is needed).
For instance, you want to created a new branch based on the
current shared location and have no plan to ever merge it back. In this
case, the lock on the shared branch should not matter to you. This is
true regardless how you implement locking, and in your scheme it will
another special case.
If you have no intention to merge a local branch back to the remote branch
it is based on, then you won't have the remote configured for this. If the
locking and lock-checking code uses the push configuration to determine
what locks make sense, it'll automatically be unrelated.
-Daniel
*This .sig left intentionally blank*
On Wed, Sep 24, 2008 at 12:15:39AM -0400, Daniel Barkalow wrote:
On Wed, 24 Sep 2008, Dmitry Potapov wrote:
quoted
What are you saying is that when I am locking some file on the current
branch, Git (or whatever script that performs this locking) should figure
out what is the original shared branch for it and lock the file there.
Or you should have to say. But "git lock <filename>" should probably
put the lock on whatever branch "git push" would push to, and similarly
for the other argument combinations that "git push" permits.
It seems to me very fragile to rely on the push configuration in deciding
what can be locked and what cannot. Besides this configuration can change
over time. So what is going to happen with locks then? Another problem:
what if I don't push anyway but usually send pull-requests?
The fact is if you cannot get your locking working in _one_ repository
then any hope that it will work when you have more than one is nothing
but a pipe dream.
quoted
Maybe, it can work, but it sounds too complex to me. I believe that my
idea using SHA-1 is better. After all, what is file? It is its content.
At least, in Git, we always identify files by their content.
Not at all; there are plenty of cases where what matters is the path, and
some things are relevant by virtue of the form of the filename which names
that content.
Whether it matters or not depends on a particular workflow and what the
developer wants to achieve. Such decisions should be taken by human
being, otherwise you are prone to do the wrong things too often.
quoted
Thus if you lock some file, you put a lock on certain SHA-1. Now,
regardless of branches and paths, this lock can work provided that you
have access to some shared location. Of course, this lock is purely
advisory, but it is good, because you may want to ignore it in some
case.
In my design, the lock (on the shared repository) is not advisory; if
someone else has it, you can't push if the new commit doesn't match the
old commit for that path.
Hey, if someone wants to push this file, it means it is already late,
because you _already_ have the situation where two people have edited
exactly the same binary file. Isn't the situation that the lock was
intended to prevent?
So, the goal should be to warn someone who is going to edit file locked
by someone else. You cannot prevent him/her from doing so, only to warn
about that.
As to pushing, it can be different policies. IMHO, the update hook is
the best place to express what push you want to allow and what not, but
some workflow may not use push at all, yet ability to lock (perhaps,
'synchronize' would be a better word here) may still be needed.
Dmitry