Subversion: is it possible to commit local revisions without pushing them, and push them at a later date - or is the lack of this feature why it's called "centralized" ?
+7
A:
It is not possible to do local commits with Subversion.
This is because, as a centralized version control system, your local working copy does not have all the information the server has about past revisions, log entries, etc. which it would have had if it was a Distributed Version Control System (DVCS).
A subversion working copy contains a copy of all files as they were checked out so you can revert changed files without contacting the server.
If you really want to do local commits you should have a look at SVK, which is built on top of Subversion and provides DVCS like features.
arturh
2009-07-03 22:47:57
Do you have experience with SVK? I've used it a bit and it seemed alright, but I don't have much faith in smooth svn uses any more. I'd imagine anything built on top of it would be just as wobbly.
jskulski
2009-07-03 23:34:48
A:
That is why it is called centralized. You could try using a repo inside a repo. One is local and the other is remote. You then commit the entire inner repository to the remote.
Manuel Ferreria
2009-07-03 22:49:28
+1
A:
You could do such a thing so if you interface the SVN Server with a GIT or Mercurial Bridge. Since GIT and Mercurial are able to do local Commits you could then use them like that. Maybe check out git-svn or something similiar (I remember there being a bazaar-svn but not sure).
SideShowCoder
2009-07-03 22:52:25
A variant of this is to 'git init' in an SVN working copy, make your local commits offline. Later, you commit the final state (or even intermediate ones) to SVN. After this you could also delete the .git directory.This would mean your working copy stays a SVN working copy, not a git-repo.
fmarc
2009-07-07 14:35:24
A:
No! git however can do this, and you can use git-svn to keep in sync with the original repository.
Rhythmic Fistman
2009-07-03 22:53:00
+1
A:
As others have said, no.
I would strongly recommend trying to use anything remotely janky with svn.
I haven't used SVK enough to recommend against it, it seemed nice enough. However I am skeptical of using anything built on top of SVN for an entire project without anything breaking. I have use SVN enough to know that even regular work cycles can toast it if you're not careful.
We use SVN at work. I have been using bzr and bzr-svn to do all my interaction with and it works wonderfully. My workflow is something like:
$ bzr branch file:///var/svn/project ~/project
(hack, hack, hack)
$ bzr commit -m "commit log"
(repeat)
when I'm ready
$ bzr push
Yes, instead of updating you have $ bzr merge and commit change (possibly shelving what you are working on) but local commits are a very nice thing, and shelving is too (shelving is like revert with a save)
I think git handles this as well. I've heard it is not as complete as bzr-svn, but I can not corroborate that.
But using a DVCS with a svn repository is a good way to go!
jskulski
2009-07-03 23:30:43