Any sympathy for switching to a distributed SCM?

zirias@

zirias@

Developer
Reading in a thread right now that somebody started to distrust svn, I just have to bring this up -- I'm sorry if this topic already exists, I tried the search, but it's hard to find concise search terms (I didn't find anything).

So, what about the idea to, again, switch the source control system, and this time to a distributed one? To make that clear, I do NOT distrust svn, I just see the drawbacks of the centralized model. Several years ago, I had all my own projects on my own svn server, but recently moved them all to github (and that's just out of laziness, having a cloud service for free at hands, why bother to setup your own git service) and I really love it. It doesn't have to be git, this just comes to mind as the most widespread open-source distributed SCM available.

Was this discussed before? Just to outline the benefits on a practical example: I'm maintaining two ports right now. With svn, I have to manage my testing changes somewhere else, copy them manually to a tree fetched with svn and test them there. When I'm done, I do a svn diff to submit a patch, and when it is accepted, I have to do the svn revert to avoid running into conflicts when updating. With git, I could just manage my own branch locally, pulling updates to an upstream branch and merging/rebasing them. It would be so much less manual work :) So, what do you think?
 
That might have been me, I think and it was unfounded.
But I, myself, are a big fan of fossil. The NetBSD projects also uses it as an option, so if this becomming a topic one may ask for their experience.
I would also like to have an option for this, but my preference is devel/fossil.
 
Never heard about fossil before, but I'll have a look. What I'm after with this is just the distributed (vs. centralized) model, which I think has a great benefit :)

edit: and yes, it was your thread, and I understood your distrust was only temporary ;) -- of course svn does it's job reliably. Your thread just gave me the impulse to post about that, because I personally think distributed SCM systems are superior.
 
Then you will love fossil. It als keeps a wiki, ticket system and web server, all in one binary. The Repo is also only one file, easily backed up and out-of-tree.
Oh, and it also can serve as a fusefs module.
 
So this discussion was there, before -- I thought so. Thanks kpa for the link. This is "anecdotal", but as I'm developing Windows software in my dayjob, I was very pleased to see some external company use the git protocol with TFS and I have to contribute there. It seems to work quite well on a large scale. Nevertheless, I'll read that wiki page now and maybe get a better view on this.
 
Zirias said:
When I'm done, I do a svn diff to submit a patch, and when it is accepted, I have to do the svn revert to avoid running into conflicts when updating.
Click to expand...
Why don't you just select theirs-conflict (or tc) when prompted? That's what I do. Or do it for all conflicts during updating with svn up --accept theirs-conflict.
Zirias said:
With git, I could just manage my own branch locally, pulling updates to an upstream branch and merging/rebasing them. It would be so much less manual work :) So, what do you think?
Click to expand...
FreeBSD already maintains repositories on GitHub, so nobody is stopping you from using https://github.com/freebsd/freebsd-ports right now :)
 
tobik said:
FreeBSD already maintains repositories on GitHub, so nobody is stopping you from using https://github.com/freebsd/freebsd-ports right now :)
Click to expand...

I noticed this a while ago, I know GIT quite thoroughly but SVN a complete alien to me and too slow for my connection. The git svn bridge sounds like a really neat solution for making SVN easier to work with, apparently you can do all the nice git stuff like rebasing etc. I didn't get very far last time I tried it with FreeBSD, can't remember the details of why, but now i've ended up with a git repo of diffs of kernel modules which is a bit annoying.
 
There's little doubt in my mind that the biggest obstacle to switching to a newer, distributed RCS is choosing one of the available options for any reason beyond "The majority of devs prefer it." There aren't many arguments against the advantages of a distributed RCS compared to a centralized one, but there's an endless debate about which distributed RCS is the best.

Git is far and away the most popular choice, but it's pretty apparent to me that this is largely because it's the first that many new *nix users are exposed to, GitHub is great, the project has Linux Torvald's reputation attached to it. Of course those might seem like the obvious reasons to me just because I absolutely prefer Mercurial---not because it's inherently better, but because I just like the way it works and the philosophy behind it.

I'm sure the change in development workflow is also a barrier, but they'd have to actually choose one before that became an issue.
 
Yeah I don't get the workflow issue, my understanding is that GIT can pretty much mimic SVN workflows and obviously add a lot of options that can only be done with distributed such as GitHubs fork merge flow... but it doesn't mean you have to use any particular one.

I'll admit the popularity isn't a good reason, I actually tried SVN and mercurial before GIT and I do believe there is more value in it that popularity... I don't have anything against mercurial, GIT just clicked with me really quickly so I switched to that, but it's not absent of weird nasty features like submodules.
 
Last edited by a moderator:
tobik said:
Why don't you just select theirs-conflict (or tc) when prompted? That's what I do. Or do it for all conflicts during updating with svn up --accept theirs-conflict.
Click to expand...
I might have to reconsider my workflow, I'm new to FreeBSD and, at the moment, maintaining ports even before I use FreeBSD in my "production" (although private) environment. The reason I didn't chose to go with "theirs-conflict" is that I want the ports tree clean ... if there would be anything that can be merged automatically (improbable, but possible), svn would silently do it. With a distributed SCM, I could make sure to have a branch that is exactly the same as upstream, while managing my changes in another local branch. What I do right now is manual copies to and from a local (and, just-in-case, hosted on github as well) git repository.

edit: more reasons for me to have a local branch are:
  1. I like to do commits one at a time, logically separating them, without the need to have a buildable state as a result ... think "feature branches".
  2. I have a few ports that aren't suitable for submission, and it's nice to have them in my own branch.
edit2: that all being said, I'm really happy FreeBSD spares me the brain-damage caused by cvs now ;) svn is indeed a decent tool and does it's job as a centralized SCM quite well, I'm only missing features provided by distributed SCMs and that's naturally not in the scope for svn. :)
 
You must log in or register to reply here.
Back
Top