[haiku-development] Re: Mercurial
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 12 Mar 2010 18:28:42 +0100
Hello John,
On 12 March 2010 16:34, John Scipione <jscipione@xxxxxxxxx> wrote:
> I am unlikely to be granted svn commit access nor do I desire it as I
> am far from a mainline developer. Consequently, the code that I write
> gets added to my local copy only. When I perform an svn update my
> changes sometimes conflict with other people's changes creating a
> maintenance chore for me. Git and mercurial include features to make
> merging easier and avoid conflicts better than subversion.
What you are really looking for is patch management tools. Luckily
there is quilt:
http://savannah.nongnu.org/projects/quilt
It is a tool for managing patches and it is SCM agnostic.
> Furthermore, I have no way to publish my changes publicly other than
> to submit a patch to this list or to the bug tracker. I only submit a
> patch when I feel that my code is worthy of inclusion. This means that
> my patches grow stale as my improvements are added to my local copy
> only, are infrequent, and are inaccessible to the public. Someone
> might want my bleeding edge patch but they can't get it. I have
> neither the ability nor the desire to setup my own Internet accessible
> source repository.
>
> Using git or mercurial would allow me to fork the project into my own
> repository and publish my changes there. github allows for an Internet
> accessible place where my fork can live. People can inspect my latest
> changes and pull them to try them out. I can easily provide a link
> where changes can be pulled from into the official repo rather than
> submit a patch. Lets face it, patches are a pain in the butt. The
> whole process becomes easier for me, the lone Haiku developer. Whether
> or not a distributed version control system is better for the project
> is debatable. However, if there are others out there like me (perhaps
> with better changes) then subversion really is hurting the project by
> hiding good code in peoples local branches rather than allowing them
> to put those changes on the Internet.
I strongly disagree with the assertion that patches are a pain in the
butt. They are small, agile and everybody knows how to handle them. If
merging changes is a problem for you, there are (graphical) tools that
help you apply patches that do not apply cleanly.
I think most of the contributed work by non-core devs is in the
category of small iterated improvements. For those changes, patches
and trac are a good way of going about tracking and including those
patches.
I do see the argument that Trac right now is not the most efficient
way of tracking patches, because there is not yet a way to get a list
of active patches. If we manage to do that, then there is no need for
a (resource hungry) bitbucket. If you still want to use an SCM for
your local patch, I think we can declare the hg and git mirrors to be
'official'.
Regards,
N>
Other related posts:
