On 08/25/2011 03:49 AM, Tom Gundersen wrote:
On Thu, Aug 25, 2011 at 1:24 AM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Thu, 2011-08-25 at 00:15 +0200, Tom Gundersen wrote:
Thanks to everyone involved with pushing this. I can not wait to get rid of SVN. Doing anything but the most trivial operations is a huge PITA.
IMHO the only nice features I like from git that aren't in SVN are bisect and the possibility to work on a local copy without being online.
That, in addition to easy branching/merging, rebasing and reverting. This is all possible with SVN of course, but it becomes much more cumbersome.
The first part is something we don't use for packaging,
We don't use it because we can't. I think we should though, especially for the non-trivial packages (that contain lots of patches or other tweaks). In order for bisection to be useful, we'd need to be able to do smaller patches, and that's not really practical without local commits.
the 2nd part is not a very big issue if we make our server faster.
Local commits have nothing to do with speed, at least not for me (once I push out my patches, I'm done for the day and go to make myself a coffee). Having local commits and simple branching/merging makes it much easier to make atomic commits, even if you are not sure if you want to push them to the repos yet (you want to test the package more first).
Local commits, pushing patches? Usually a common commit for packages don't have more than 2 lines of changes. Do you really need local commits for that, branching and merging? What I found it interesting is that pro git are those who don't do a lot of packaging around here and have now only couples of packages in their maintenance. You guys describe a workflow for a coding project and I understand how cool is git, but for packaging I don't see any reason to use it.
At the moment I have the choice between making all my changes, testing the resulting package and committing with message "lots of churn". Or committing after each change, but then I'd only end up testing the package after pushing all the commits.
You are doing testing wrong. What about commit only after everything is tested?
All that said, I think the most important point to keep in mind when comparing SVN and git is what are people used to and comfortable with. And people are going to be used to whatever upstream are using (that's after all where we get our patches, and where we do our bisection, submit our fixes, etc).
I don't know what the global statistics are like as I only maintain a very few number of packages, but looking at the projects I have currently checked out (my own and related packages): 28 use git, 1 use CVS (but I can't deal with that and use a git mirror) and 1 use svn (that's us).
I don't have a full understanding of the details of the proposed git solution, so all I'm saying is that I'm positive to the idea.
Cheers,
Tom
-- Ionuț