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