Slashdot Mirror

If you're looking for distributed version control, and you don't dislike subversion's general paradigm, you might be interested in svk

Basically it's a distributed version control system built on subversion's libs. Pretty slick if you're into that sort of thing...

You think he could turn SVN into a distributed CMS with a few patches?

No more so than starting from scratch would require. This seems to be the approach svk is taking, and seems to be pretty far along.

I must admit I did not really understand your system setup. It looks to me that you could replace it with a distributed versioning system, like SVK. Also probably of interest is this article. It talks about Darcs, but most of the fundamental concepts about distributed versioning systems are the same (across SVK, darcs, monotone, arch, etc).

SVK works well with subversion, and has support for star merges. The ability to work offline is another cool bonus. On the flip side, documentation kinda sucks right now, but its command set for every day use works in pretty much the same way as subversion's.

For example now Linus is developing some custom made programs to manage patches, and has discarded all Open Source alternatives like Arch, SVK, and others without any given explanation or reason.

Perhaps the reason is that he does not want to promote a Free BitKeeper alternative.

But svk would probably be just fine.

It is also quite easy to use svk together with a central Subversion repository, to get the best of both worlds.

Is Subversion decentralized? Even the Subversion maintainers admit that the Linux kernel development atmosphere doesn't mesh well with the centralized CVS/SVN model. There exists SVK, a decentralized hack on Subversion, but is it mature?

SVK is a very sweet extension to SVN and actually rocks my world! :)

on the other hand, svk does support distributed repositories. and it works with subversion.

RCS and CVS are definitely non-starters.

There's also SVK, which is like decentralized Subversion.

ps - now that I look at it again, it appears that svk has grown beyond a subversion add-on and supports other repository architectures.

Subversion doesn't come close to being replacement for BitKeeper. Not that it's a bad tool - it just doesn't support distributed repositories at all. Different philosophy.

What about svk?

svk, uses a big pile of perl on top of subversion to implement a distributed source control model not too different from bk.

It's very new but some brave folks seem to be using it for production development already. It helps that you can use it to mirror conventional svn repositories without special arrangements..

You can use SVK to mirror a SVN repository: http://svk.elixus.org/

If you have an opportunity to, chuck it and use Subversion instead.

Just add SVK to that and you got a nice decentralized version control system.

However I'm keeping my eye on it. When they support changesets and distributed repositories, as well as transparent CVS support for legacy clients, I'll be first in line.

In that case, do check out the svk project, which supports distributed repositories, transparent CVS mirroring, and has an almost identical command set as Subversion.

One thing I really like about svk is that it can choose to present itself as a "single stack of revisions" monolithic system, or as a "multiple stacks, star-merged back and forth" decentralized system, or even a "shallow stack of patch chains, swapped freely" system, based on the current needs of the user.

I am implementing a darcs-compatible command set and patch tracking algorithm for svk, which should be merged to the main trunk on 0.23 or 0.24,

Also, svk interoperates with existing p4, cvs, svn (and soon arch) repositories, as you don't have to convince everybody else to use the same system.

I sincerely encourage you to play with svk. The next biweekly release (0.22), to be released next Monday, would be an excellent choice.

However I'm keeping my eye on it. When they support changesets and distributed repositories, as well as transparent CVS support for legacy clients, I'll be first in line.

In that case, do check out the svk project, which supports distributed repositories, transparent CVS mirroring, and has an almost identical command set as Subversion.

One thing I really like about svk is that it can choose to present itself as a "single stack of revisions" monolithic system, or as a "multiple stacks, star-merged back and forth" decentralized system, or even a "shallow stack of patch chains, swapped freely" system, based on the current needs of the user.

I am implementing a darcs-compatible command set and patch tracking algorithm for svk, which should be merged to the main trunk on 0.23 or 0.24,

Also, svk interoperates with existing p4, cvs, svn (and soon arch) repositories, as you don't have to convince everybody else to use the same system.

I sincerely encourage you to play with svk. The next biweekly release (0.22), to be released next Monday, would be an excellent choice.

However I'm keeping my eye on it. When they support changesets and distributed repositories, as well as transparent CVS support for legacy clients, I'll be first in line.

In that case, do check out the svk project, which supports distributed repositories, transparent CVS mirroring, and has an almost identical command set as Subversion.

One thing I really like about svk is that it can choose to present itself as a "single stack of revisions" monolithic system, or as a "multiple stacks, star-merged back and forth" decentralized system, or even a "shallow stack of patch chains, swapped freely" system, based on the current needs of the user.

I am implementing a darcs-compatible command set and patch tracking algorithm for svk, which should be merged to the main trunk on 0.23 or 0.24,

Also, svk interoperates with existing p4, cvs, svn (and soon arch) repositories, as you don't have to convince everybody else to use the same system.

I sincerely encourage you to play with svk. The next biweekly release (0.22), to be released next Monday, would be an excellent choice.

However I'm keeping my eye on it. When they support changesets and distributed repositories, as well as transparent CVS support for legacy clients, I'll be first in line.

In that case, do check out the svk project, which supports distributed repositories, transparent CVS mirroring, and has an almost identical command set as Subversion.

One thing I really like about svk is that it can choose to present itself as a "single stack of revisions" monolithic system, or as a "multiple stacks, star-merged back and forth" decentralized system, or even a "shallow stack of patch chains, swapped freely" system, based on the current needs of the user.

I am implementing a darcs-compatible command set and patch tracking algorithm for svk, which should be merged to the main trunk on 0.23 or 0.24,

Also, svk interoperates with existing p4, cvs, svn (and soon arch) repositories, as you don't have to convince everybody else to use the same system.

I sincerely encourage you to play with svk. The next biweekly release (0.22), to be released next Monday, would be an excellent choice.

I assume you mean BitKeeper and Arch. There is also SVK. The homepage is a Wiki, which I find kind bletcherous, but I hear it is pretty good (I have no personal need for a distributed RCS). It's based on Subversion, which I do use and is excellent.

SVK supposedly has distributed revision control and different flavours of merging. SVK uses Subversion as a versioned filesystem.

BK uses a more distributed development model instead of having one central server, which allows people to maintain their own version controlled source tree from which Linus (or anyone) can pull patches from. This is more like Arch or SVK than CVS or Subversion. Although in the end it performs a similar function, the difference is fairly significant.

Subversion does not support decentralized development.

Check out svk. That project uses svn as the base filesystem for a distributed version control system, a la bitkeeper. I really know nothing about it, but it may be (sort of) what you are looking for.

By the way, why is lack of support for decentralized development a "major limitation"? The only (open source) project I've heard of that needs it is the kernel. Most commercial software also appears to be centralized.

Database & log files take up a LOT of space.

svnadmin comes with a command that you run on your repository called list-unused-dblogs, it will tell you what Berkeley DB log files are unused, which you can then delete. But usually people will want to just run:

svnadmin list-unused-dblogs repository | xargs rm

Quite hard to share repositories

Decentralized repositories is one feature Subversion does not have (yet). But take a look at SVK which is what the Subversion developers currently recommends to anyone looking for this feature.

No way to mark your branches (if you accidentally check out the directory containing your branches, you just got 50 gigs of 99.9% identical files...)

Which is why the current best practice is to lay out your repository like this:

/
/trunk
/tags
/branches

You did read the online Subversion O'Reilly book, didn't you?

No distributed development

I don't know what you mean by this, and how it differs from your "shared repositories" point above. Can you disambiguate?

Thomas

Database & log files take up a LOT of space

This has got a lot better recently, and with the latest Berkeley DB you don't have to worry about cleaning up the log files. I find that CVS and subversion repository size are now roughly the same.

• Quite hard to share repositories
• No distributed development
• Pretty weak merging

The SVK project (basically distributed repositories built on top of subversion) is addressing a lot of these issues. Seems to be coming along nicely. The merge support isn't quite at the same level as arch yet, but the naming and command line syntax is a lot nicer IMHO.