This is most instructive.<br><br>Since one of our goals is to foster community participation and VTK growth, more flexibility in the development workflow appeals to me. I am an old dog but I see the merits of this distributed approach, as long as there is enough controls in place to keep the "blessed" core of VTK stable.<br>
<br>Will<br><br><div class="gmail_quote">On Thu, Oct 8, 2009 at 9:23 AM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> As someone that appears to have lots of experience using all these tools,<br>
> what is your personal preference?<br>
<br>
</div>It is hard to give a straightforward answer so I will give a long,<br>
oblique answer instead :-) If you want an executive summary, jump to<br>
the last paragraph.<br>
<br>
I now do pretty much all of my development using git. I use the git<br>
repository that tracks ParaView maintained by Brad King. We also push<br>
it here: <a href="http://github.com/Kitware/ParaView/" target="_blank">http://github.com/Kitware/ParaView/</a> so that it is publicly<br>
accessible. I love git as a version control system. It is well-design<br>
and very powerful. Having a local repository allows you to do many<br>
things you cannot do with a centralized version control system:<br>
<br>
* Having the luxury of version control even if you are not ready to<br>
publish your work or don't have network access. This saved me from<br>
loosing work many many times. Plus I can go back to something I did 2<br>
weeks ago and it is documented in the commit log. I can do diffs and<br>
such to remember what I did before.<br>
<br>
* Very very fast.<br>
<br>
* I can do fancy things like "git grep" to search through a version in<br>
the repository without even checking it out<br>
<br>
Any downsides? Not really. BUT we don't have to switch the main VTK<br>
repository to git for me to make use of any of this. Tracking with git<br>
(specially svn) works really well.<br>
<br>
So what is the difference between svn and git (or mercurial) on the<br>
central repo? Well, there is one thing you cannot do when tracking<br>
cvs/svn with git/mercurial: merge changes the DVCS way. A common<br>
workflow for DVCS is as follows:<br>
<br>
1. Branch the trunk to work on something (ideally ALL development<br>
happens on branches). The branch is local to the user's repo.<br>
2. Write code, commit, repeat many times.<br>
3. Now I want changes from the trunk because I want to see if I broke<br>
something in the latest version. Merge from trunk. I am still on the<br>
branch but the last commit now points to the branch and trunk as<br>
parents.<br>
4. Repeat 2 and 3 multiple times<br>
5. Now I want to commit to the trunk. I checkout the trunk and I merge<br>
my branch to the trunk. I then push this commit (after testing of<br>
course). This automatically pushes all of the commits that this commit<br>
depends on upstream.<br>
<br>
The final version of the central repo will have the whole graph of all<br>
the commits I made. You cannot do this when the central repo is<br>
cvs/svn because they use a tree to represent the history instead of a<br>
DAG. So, you are stuck with linearizing your history by "rebasing"<br>
instead of merging. Rebasing essentially means changing the history by<br>
pulling all commits from trunk and putting them before my changes on<br>
the branch - which moves the branch point to the end of trunk. It<br>
works but it is not the DVCS way.<br>
<br>
Am I making sense? This is hard to explain.<br>
<br>
The bottom line? Personally, I would love it if we were using git or<br>
mercurial as our central repo. It took me a long time to get used to<br>
DVCS (as much as I got used to it) but now that I am there, I love it.<br>
BUT a DAG history is harder to grasp and work with than a tree history<br>
so it would be a burden on some developers.<br>
<br>
I think that the choice depends on the answer to this question: Are we<br>
going to do a lot of distributed development in VTK?<br>
* If every team working on core VTK will have write access to the VTK<br>
repository, they can branch as necessary (specially with light-weight<br>
branching of svn) to do their work that can impact stability. Then svn<br>
is the best choice.<br>
* If many teams working on core VTK will not have write access<br>
(because we don't trust them or we don't have the resources to keep up<br>
with them), DVCS is the right choice.<br>
If we can focus on answering this question, we can easily make a<br>
decision between svn and git/hg.<br>
<br>
I apologize for the long message.<br>
<font color="#888888"><br>
-berk<br>
</font><div><div></div><div class="h5"><br>
<br>
On Mon, Oct 5, 2009 at 3:46 PM, Claudio Silva <<a href="mailto:csilva@sci.utah.edu">csilva@sci.utah.edu</a>> wrote:<br>
> Berk,<br>
><br>
> Thanks for the links. At Utah, we've moved to SVN a few years back, and<br>
> although I have used git a bit, I wouldn't consider myself an expert.<br>
><br>
> As someone that appears to have lots of experience using all these tools,<br>
> what is your personal preference?<br>
><br>
> Claudio.<br>
><br>
><br>
><br>
> On Oct 5, 2009, at 12:24 PM, Berk Geveci wrote:<br>
><br>
>> I don't think that we should think this in terms of Git vs. SVN. We<br>
>> should instead think of it in terms of centralized version control<br>
>> (CVS, SVN etc.) vs. distributed version control. These two articles<br>
>> are a good summary of the differences between the two:<br>
>><br>
>> <a href="http://www.ericsink.com/entries/dvcs_dag_1.html" target="_blank">http://www.ericsink.com/entries/dvcs_dag_1.html</a><br>
>> <a href="http://www.ericsink.com/entries/dvcs_dag_2.html" target="_blank">http://www.ericsink.com/entries/dvcs_dag_2.html</a><br>
>><br>
>> If we decide that distributed version control is the right thing for<br>
>> VTK, we can either pick a tool that is well supported on all platforms<br>
>> we are interested in (probably Mercurial) or we can wait until one of<br>
>> them becomes mature enough before switching.<br>
>><br>
>> If we decide that centralized version control is the right thing, we<br>
>> should probably switch to SVN as soon as we can. Tracking SVN with Git<br>
>> is possible but it is more limited than using Git or Mercurial for<br>
>> everything (see the articles above to understand why).<br>
>><br>
>> -berk<br>
>><br>
>> On Mon, Oct 5, 2009 at 3:33 AM, Paolo Quadrani <<a href="mailto:p.quadrani@cineca.it">p.quadrani@cineca.it</a>><br>
>> wrote:<br>
>>><br>
>>> Dear all,<br>
>>> attached you can find a document that make a comparison between Git and<br>
>>> SVN.<br>
>>><br>
>>> For new version of our MAF framework we decided to use SVN as main<br>
>>> repository for code sharing and then each developer if want can have its<br>
>>> own<br>
>>> Git local repository to manage its own history for its local code<br>
>>> changes,<br>
>>> and maintain changes also if it has no network connection.<br>
>>><br>
>>> Just a comment on code contribution: if someone wants to contribute with<br>
>>> its<br>
>>> code, I think that you cannot accept code without documentation (in<br>
>>> doxygen<br>
>>> style for example) and the related test class that prove that the code<br>
>>> works.<br>
>>><br>
>>> I can propose also that submitting code could be done through a web<br>
>>> interface that present a form to be filled with fundamental information<br>
>>> that<br>
>>> the code must have and you decide what is important for you and for<br>
>>> validating the code. This means that you filter at begin the code and<br>
>>> accept<br>
>>> only valid code and don't loose time to review tons of classes sent via<br>
>>> mail.<br>
>>> There should be also some pre checks for checking that coding conventions<br>
>>> are respected. For MAF we have some python scripts that check that<br>
>>> classes<br>
>>> have the documentation inside and it is written in doxygen style, scripts<br>
>>> that check that code is written respecting the coding convention and so<br>
>>> on.<br>
>>><br>
>>> Cheers<br>
>>><br>
>>> Paolo Quadrani<br>
>>> _________________________________<br>
>>> CINECA<br>
>>> System and Technology Department<br>
>>><br>
>>> Via Magnanelli 6/3 40033<br>
>>> Casalecchio di Reno<br>
>>> Italy<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Arb mailing list<br>
>>> <a href="mailto:Arb@vtk.org">Arb@vtk.org</a><br>
>>> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/arb" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/arb</a><br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> Arb mailing list<br>
>> <a href="mailto:Arb@vtk.org">Arb@vtk.org</a><br>
>> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/arb" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/arb</a><br>
><br>
><br>
_______________________________________________<br>
Arb mailing list<br>
<a href="mailto:Arb@vtk.org">Arb@vtk.org</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/arb" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/arb</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>William J. Schroeder, PhD<br>Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
<a href="http://www.kitware.com">http://www.kitware.com</a><br>(518) 881-4902<br>
<input id="gwProxy" type="hidden"><input onclick="jsCall();" id="jsProxy" type="hidden"><div id="refHTML"></div>