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 <iveqy@xxxxxxxxx>:
> 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: iveqy@xxxxxxxxx
--
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