<div dir="ltr">Hi,<br>I agree fully with Jonathan here.<br><br>Sylvestre pointed out a problem with the current work flow, i.e. that of keeping a development Branch up to date with ongoing fixes in the trunk - this I agree is a pain and I'm not envious of the configuration managers job.<br>
<br>But (and its a big but) you stopped short of saying how git will solve this - all you said was "We intend to address this kind of issue".<br>As far as I can see if you want the development branch to contain recent bug fixes then someone somewhere is going to have the pain of merging them in and the choice of version control tool won't change this - you'll still have this problem.<br>
<br>Maybe I'm missing the point here....<br><br>Barry<br><br><div class="gmail_quote">2008/9/30 Jonathan Blanchard <span dir="ltr"><<a href="mailto:BlanchardJ@ieee.org">BlanchardJ@ieee.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
First It's true that I do not know the amount of contribution from the<br>
community out of the INRIA. Indeed If external contribution are rare<br>
it will not affect people too much.<br>
<br>
Now on the other hand I really do not see how git will fix the problem<br>
you just said. Commit are still made either to branch or trunk in git.<br>
The model is not that different from svn you need to manually shift<br>
around and merge stuff between branches and trunk. (Well that is the<br>
way I see it). I mean each modification from the trunk will either be<br>
fully merged on the branches or merged manually by selecting which<br>
modification get merged into branches. Git work somewhat the same way.<br>
<br>
I do not try to discourage your choice. I mean at the end it's<br>
your(Scilab dev team) concerns and this could be more of a<br>
philosophical debate but I do often use the svn repo as I'm coding<br>
from the trunk and the idea of dealing with git is a bit discouraging.<br>
Especially the type of work flow and repository structures git<br>
encourage. Or maybe it's just me who fear changes :) (Or most of<br>
Linus's opinions....).<br>
<font color="#888888"><br>
Jonathan Blanchard<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
On Tue, Sep 30, 2008 at 11:45 AM, Sylvestre Ledru<br>
<<a href="mailto:sylvestre.ledru@scilab.org">sylvestre.ledru@scilab.org</a>> wrote:<br>
> Le mercredi 24 septembre 2008 à 19:36 -0300, Jonathan Blanchard a<br>
> écrit :<br>
>> I do believe that git shift the<br>
>> difficulty of working with a distributed revision system from the<br>
>> projects managers toward the users and collaborators.<br>
> Hmm, most of the developers of Scilab are working closely at the INRIA.<br>
> We see each others every day. Therefor, shifting the difficulty upon the<br>
> dev is no big deal.<br>
><br>
> To detail why we need it, I can take an example how it is working now.<br>
><br>
> At the moment, almost all the team & contributor are working on the<br>
> current trunk.<br>
> However, we have some people who are working on cleaning up and<br>
> rewriting some functions in the  elementary functions module.<br>
> These modifications are risky, therefor, we don't want to include them<br>
> in the trunk but we want to be able to take modifications (on this<br>
> module) from the trunk and merge them into this branch. For this, each<br>
> night, an email is sent to the guy in charge of this to check if the<br>
> modification on trunk/elementary_functions should be incorporated in his<br>
> branch.<br>
><br>
> It is a boring work and it is common to forget things...<br>
><br>
> We intend to address this kind of issue.<br>
><br>
> We also expect to develop collaborative works (ie, some guys working on<br>
> a distinct branch and pushing in the master their work once it is good<br>
> enough).<br>
><br>
> Sylvestre<br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div>