On Tue, Sep 28, 2010 at 1:02 PM, Grzegorz Sobanski <s...@boktor.net> wrote: > > Exactly because it is distributed :)
It is not distributed by default, i.e. you are still constrained to the working copy on your machine, or you need to register account on GitHub, which don't support OpenID/OAuth/etc., and which tracker suxx. More than that - you can't just upload your patches there - first you need to upload the repo, then make a fork, then fork from that fork and then push your patches there. > That means, someone does not need to have commit access to the svn > repository on t-h.o to create their own branches, modifications etc. You need access only if you want your modifications to be public, but even if you have your own branch on GitHub - it doesn't mean it will be integrated if maintainer is not here - you will still need to go through usual adoption process. > If you want to do only a simple change, a patch is sufficient, > but doing something more is PITA if you can't commit during the work > (you lose all the benefits of repository if you have to develop a big > feture without the possibility to do commits). What's wrong with 'hg init' in svn checkout? I've maintained my Python patches in MQ in svn checkout and I can't say that this is a PITA. If there are any inconveniences - they could be easily scripted. I am just lazy. `hgsubversion` should provide you with a better experience. > Second, even if you have commit access to the main svn repository, > you sometimes want to have private branches, that you do not share > with the world, to try, experiment, etc. hg init > Third, svn does not have branches, and merging branches there is just > a nightmare compared to mercurial or git. For simple merges it is ok. I doubt trac hacks need anything more serious like cross-merges between feature branches with optional cherry picking and stuff. > And last, I don't know about mercurial, but git has just million times > better experience when working with it in command line then svn. git-svn ? > IMHO if you try hg or git, even in two people cooperation (or even > individually), you just do not want to go back to the dark svn ages ;) I've tried Mercurial and I use it, and I use it with SVN without too many problems. As for what Git has better than Mercurial. For me - without GitHub there is nothing, so unless you want to make a GitHub out of TH, there is no point in spreading FUD. In conclusion. It you can't exec "svn diff > patch.diff" and upload to tracker, then DVCS is not for you. If you can - then there is nothing hard in doing 'hg init' and tracking your chained changes in mercurial queue. I've seen some DVCS proponents who've learned DVCSes only to say that it is "of course better than SVN", but they expected more, because there is still something wrong with it. So I guess it can be endless. =) I would like to see what Subversion 1.7+ will come to. I guess there will be some kind of patch queues for the above use cases. -- anatoly t. _______________________________________________ th-users mailing list th-users@lists.trac-hacks.org https://lists.trac-hacks.org/mailman/listinfo/th-users
