OSDev.org

I wasn't aware that this is a SVN thread. And actually, I didn't even say he should be using git, but just suggested to have a look at a DVCS (which includes for example hg - a tool that I personally avoid whenever possible). Not even for using it for daily work, but just for a very specific use case.

The real sad, sad fact is that you can't propose a solution for a problem any more without getting into a flame war. The question was how to backup a SVN repo when you don't have shell access to it and the provider doesn't have a web interface for dumping it. Your solution is to switch the provider. For me, the obvious answer is to use a git-svn checkout, which is a tool that gives you a completely copy of the whole repo and can be restored into a fresh SVN repo at any time. What's wrong with using a tool that does the job? Except of course that its name contains the letters git.

Documentation, user interface etc. may all be very valid reasons why a tool is not the right thing for you, they still remain subjective. They don't mean that the tool doesn't work for anyone else. Even more so if the only other suggestion is to switch the provider. If there are no other tools that do the job, I tend to use the crappy tool instead of doing nothing.

Kevin wrote:The question was how to backup a SVN repo when you don't have shell access to it and the provider doesn't have a web interface for dumping it.

The talk was that rdos doesn't have backups of his repos. It was not clarified yet whether he has shell access or a web interface. (He might have both, just being unaware of either. We didn't get to that.)

Yes, if both is a "no", git-svn is a good workaround for the problem.

Your solution is to switch the provider. For me, the obvious answer is to use a git-svn checkout, which is a tool that gives you a completely copy of the whole repo and can be restored into a fresh SVN repo at any time. What's wrong with using a tool that does the job? Except of course that its name contains the letters git.

The "wrong" part of it is that a provider not providing access to full repo backups is IMHO not competent enough to get all the other things right that a provider might get wrong. Like, providing reliable service, manning the hotline during holidays etc.

Using a tool from the git toolbox to solve a shortcoming of the provider is a good workaround, but a workaround nevertheless.

Documentation, user interface etc. may all be very valid reasons why a tool is not the right thing for you, they still remain subjective.

In that case, there are no "objective" reasons for one tool or another...

Solar wrote:In that case, there are no "objective" reasons for one tool or another...

Well, you might have a point there. I guess in theory I could use any VCS for my work, it would just require different workflows and be a bit unconvenient (not to say painful). But objectively I guess I could work around the missing features at the cost of efficiency.

Okay, I'll admit that "objective" facts don't matter in this discussion if you understand it this way.

If the host really doesn't give you svnadmin dump, something like git-svn is almost a requirement. (of course, moving hosts is as well, but how do you go about that?)

I do think git's index and storage model give it a huge advantage over other DVCSs, the interface isn't horrible, and the 3rd-party documentation is very good.

The ability to do things like cheap branching, interactive rebase, etc. before merging or pushing commits is also a huge advantage over subversion in that you can keep the entire master branch stable and even do deployment with "git push", but that's mostly a DVCS advantage.

I have shell access, but I rarely use it, and I don't know if the svnadmin command is supported or not (but it probably is).

Solar wrote:As I said, there are other reasons, too: Documentation, complexity, learning curve, workflow, tool integration, access control. There are more which can't be shrunk into simple bullet points.

These are all the reasons im sticking with SVN for the reasonable time being.

What use is distributed version control for a small number of developers on projects such as these?

Right now, my OS has one developer... me.

However my svn repository has coped fine with up to 20 developers on other projects which werent exactly trivial projects so yes, for now SVN works fine for me.

</2 pence worth>