Re: Locking files / git
On 09/18/2013 03:42 PM, Nicolas Adenis-Lamarre wrote:
> Thanks a lot for your answer.
> That's really good arguments that i was waiting for and that i have
> not get until now.
>
> My comprehension now :
> - it's not easy to maintain several versions of a binary file in parallel.
> So basically, it's not recommanded to have complex workflow for binary files.
> In case the project has a low number of binary files, it can be handle
> by simple communication,
Yes. Since you mentioned gitolite in your original post, I assume you
read this caution also in the doc [1]:
"Of course, locking by itself is not quite enough. You may still get
into merge situations if you make changes in branches. For best
results you should actually keep all the binary files in their own
branch, separate from the ones containing source code."
The point is that locking and distribution don't go together at all.
The **core** of distributed VCS is the old "coding on an airplane"
story. What if someone locks a file after I am in the air, and I manage
to get in a good 4 hours of solid work?
CVCSs can also get into this situation, but to a lesser extent, I think.
At least you won't be able to commit!
[1]: http://gitolite.com/gitolite/locking.html
> In case the project has a lot of binary files, a simple workflow with
> a centralized workflow is recommanded
> - git doesn't hate locks, it's just that it's not the layer to
> implement it because git is workflow independant. Locks depend on a
> centralized server which is directly linked to the workflow.
>
> I'm not trying to implement a such workflow. I'm just curious, reading
> a lot of things about git, and trying to understand what is sometimes
> called a limitation of git.
It's not a limitation of git. It's a fundamental conflict between the
idea of "distributed" and what locking necessitates.
> A simple line in the documentation to say that locking should be
> handled in the upper layer (and it's done for example in gitolite)
> because it's dependant of the workflow could help some people looking
> about that point.
For people who don't realise how important the "D" in DVCS is, and
assume some sort of a central server will always exist, this "simple
line" won't do. You'd have to explain all of that.
And for people who do understand it, it's not necessary :-)
> Thanks a lot for git.
>
> 2013/9/17 Fredrik Gustafsson :
>> On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:
>>> Ooops. It seems that each time somebody says these two words together,
>>> people hate him, and he is scorned by friends and family.
>>>
>>> For the moment, i want a first feedback, an intermediate between
>>> "locking is bad" and "ok", but i would prefer in the negativ answer
>>> something with arguments ("Take CVS as an example of what not to do;
>>> if in doubt, make the exact opposite decision." is one), and in the
>>> positiv answer, good remarks about problems with my implementation
>>> that could make it better.
>>
>> So working with locks and text-files is generally stupid to do with git
>> since you don't use git merging capabilities. Working with binary files
>> in git is stupid because git doesn't handle them very well because they
>> the deltas can't be calculated very good.
>>
>> It seems to me that if you need to do locking one of the above scenarios
>> is true for you and you should not use git at all.
>>
>> However, there's always the case when you've a mixed project with both
>> binary and text-files. In that case I believe Jeff gave an excellent answer.
>>
>> But think twice, are you using git in a sane way? Even a small binary
>> file will result in a huge git repo if it's updated often and the
>> project has a long history.
>>
>> --
>> Med vänliga hälsningar
>> Fredrik Gustafsson
>>
>> tel: 0733-608274
>> e-post: iv...@iveqy.com
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Locking files / git
On 09/18/2013 01:15 AM, Nicolas Adenis-Lamarre wrote: > Ooops. It seems that each time somebody says these two words together, > people hate him, and he is scorned by friends and family. > > However, > - gitolite implement it (but gitolite is not git). No. It pretends to implement it, for people who absolutely must have something and are willing to play by the rules. Quoting from the doc [1], "When git is used in a truly distributed fashion, locking is impossible". I wrote it as a sort of bandaid, and that is all it is. "Implement" is too kind a word. regards sitaram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Locking files / git
On Tuesday, September 17, 2013 09:45:26 PM Nicolas Adenis-Lamarre wrote: > Ooops. It seems that each time somebody says these two words together, > people hate him, and he is scorned by friends and family. See the thread "intend-to-edit flag" for one implementation idea: http://git.661346.n2.nabble.com/intend-to-edit-flag-td7591127.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Locking files / git
Thanks a lot for your answer.
That's really good arguments that i was waiting for and that i have
not get until now.
My comprehension now :
- it's not easy to maintain several versions of a binary file in parallel.
So basically, it's not recommanded to have complex workflow for binary files.
In case the project has a low number of binary files, it can be handle
by simple communication,
In case the project has a lot of binary files, a simple workflow with
a centralized workflow is recommanded
- git doesn't hate locks, it's just that it's not the layer to
implement it because git is workflow independant. Locks depend on a
centralized server which is directly linked to the workflow.
I'm not trying to implement a such workflow. I'm just curious, reading
a lot of things about git, and trying to understand what is sometimes
called a limitation of git.
A simple line in the documentation to say that locking should be
handled in the upper layer (and it's done for example in gitolite)
because it's dependant of the workflow could help some people looking
about that point.
Thanks a lot for git.
2013/9/17 Fredrik Gustafsson :
> On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:
>> Ooops. It seems that each time somebody says these two words together,
>> people hate him, and he is scorned by friends and family.
>>
>> For the moment, i want a first feedback, an intermediate between
>> "locking is bad" and "ok", but i would prefer in the negativ answer
>> something with arguments ("Take CVS as an example of what not to do;
>> if in doubt, make the exact opposite decision." is one), and in the
>> positiv answer, good remarks about problems with my implementation
>> that could make it better.
>
> So working with locks and text-files is generally stupid to do with git
> since you don't use git merging capabilities. Working with binary files
> in git is stupid because git doesn't handle them very well because they
> the deltas can't be calculated very good.
>
> It seems to me that if you need to do locking one of the above scenarios
> is true for you and you should not use git at all.
>
> However, there's always the case when you've a mixed project with both
> binary and text-files. In that case I believe Jeff gave an excellent answer.
>
> But think twice, are you using git in a sane way? Even a small binary
> file will result in a huge git repo if it's updated often and the
> project has a long history.
>
> --
> Med vänliga hälsningar
> Fredrik Gustafsson
>
> tel: 0733-608274
> e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Locking files / git
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:
> Ooops. It seems that each time somebody says these two words together,
> people hate him, and he is scorned by friends and family.
>
> For the moment, i want a first feedback, an intermediate between
> "locking is bad" and "ok", but i would prefer in the negativ answer
> something with arguments ("Take CVS as an example of what not to do;
> if in doubt, make the exact opposite decision." is one), and in the
> positiv answer, good remarks about problems with my implementation
> that could make it better.
So working with locks and text-files is generally stupid to do with git
since you don't use git merging capabilities. Working with binary files
in git is stupid because git doesn't handle them very well because they
the deltas can't be calculated very good.
It seems to me that if you need to do locking one of the above scenarios
is true for you and you should not use git at all.
However, there's always the case when you've a mixed project with both
binary and text-files. In that case I believe Jeff gave an excellent answer.
But think twice, are you using git in a sane way? Even a small binary
file will result in a huge git repo if it's updated often and the
project has a long history.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Locking files / git
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote: > Ooops. It seems that each time somebody says these two words together, > people hate him, and he is scorned by friends and family. And strangers on mailing lists. :) > However, > - gitolite implement it (but gitolite is not git). Yes, and I think that distinction is important. Locking is fundamentally about having a centralized server. Even if you have some decentralization (e.g., let's imagine two divisions of a company that work as peers), the whole point of the lock is that multiple people are communicating with the same lock server (so in that same example, from the perspective of people in those divisions, there is a central server for each division, and that would be the lock server). Git itself does not know know or care about your workflow, and whether the remote you are pushing to is central or not. Having a lock server would be unlike the rest of git. Whereas gitolite, since it is about managing access to a centralized repository, is a good place to handle locking. In other words, I do not think locking is inherently bad. It is only that it is useful for a subset of workflows that git provides. So I don't think that git is the right place to implement it; rather it should be built on top, either standalone or as part of other tools that already assume some centralization. > I want to explain how I could implement it. > [...] That all sounds like a reasonable workflow, but I think you could just as easily implement it on top of git. In particular, the protocol does not have any room to communicate this data. So you are already going out-of-band over ssh, or something similar. The only support you need from git is to auto-unlock the files after a push. And I think you could do that using a post-receive hook. And indeed, you would not want git itself to do it anyway, because the rules for when to unlock are going to depend on your workflow (e.g., which branches a commit must hit to trigger an unlock). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Locking files / git
Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
However,
- gitolite implement it (but gitolite is not git).
- In the documentation, each time the need is evocated, it is replace
by "do communication, don't use git for that". I'm still looking for
the good way to communicate this information. In my humble opinion,
git is a communication tool.
I won't explain here why it could be a if not good, at least helpfull
new feature (and everybody is not mandatory to use new feature),
I've still heard no argument about why it could not be accepted in git
better than "locking is bad".
I want to explain how I could implement it.
Firstly, it would (in the general form ; some options could be added)
alter no existing command of git.
It would add 3 new commands :
- git lock [path]
- git unlock [path]
- git lslock
It would add 2 new files in .git :
- lockserver containing a ssh url of the git repository, not necessary
the source of the clone (in fact, the same content of the lockserver
file in the source of the clone so that people gets the same lock
server)
- lockedfiles containing the list of pathes of locked files (plus name
of the people locking, date) on the lock server.
git push would not be altered, however, you can imagine an option to
unlock all locked files by yourself.
the 3 new commands would require a communication to the lock server.
note that the idea is that everybody get the same lock server in any workflow.
In case there was no server defined on the original git repository,
you have to communicate so that people configure the lockserver file.
git lock would put the path provided into the lock server
git unlock would remove the path provided from the lock server
git lslock would ask pathes to the lock server
You must have rules on your project, for example, lock a .doc file
each time you modify it.
If you follow that guideline, you’ll be fine. If you don’t, people
will hate you, and you’ll be scorned by friends and family.
If you push a file which is not locked by you, any problem, it will
push (eventually, telling you that the file was locked and that your
project has some rules).
What about automatic unlocking to prevent from forgetting to unlock :
Something like pushing when the push server is the same as the lock
server could automatically unlock the file.
The question is when to unlock when you have a complex workflow with a dictator.
I agree i've not the best answer for the moment. Something like when
the developper have the files back, identically from the source of the
dictator. This point could be think more.
Scenario :
@alice : git lock src/main.c
@bob : git lock src/main.c
fatal: file src/main.c locked by alice
@alice : git unlock src/main.c
@bob : git lock src/main.c
For the moment, i want a first feedback, an intermediate between
"locking is bad" and "ok", but i would prefer in the negativ answer
something with arguments ("Take CVS as an example of what not to do;
if in doubt, make the exact opposite decision." is one), and in the
positiv answer, good remarks about problems with my implementation
that could make it better.
Perhaps this subject has already been discussed and is closed, in this
case, sorry, just give me the link i've not found please.
Nicolas Adenis-Lamarre
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
