TortoiseSVN could be a DVCS

I've been using SVN for years, but it's about to become obsolete? Hard to believe, but Git's popularity is surging rapidly, and so are other distributed version control systems like Mercurial and Bazaar. But I just can't believe that Subversion can't adapt to the changing times. There are so many SVN users out there. And I really think TortoiseSVN (TSVN) is the key. With the very simple scripting I was able to duplicate a DVCS with 2 TSVN repositories. The basic idea is that each person, clones/forks an entire repository, which is stored on there machine. Now in SVN, these repositories might be able to sync with each other, but a repo can't be a mirror and a working copy at the same time. So the trick is to save the diffs and patches and play them back in order. I think the patches should be named with hashes just like in Git and Hg. Easy!

Update (2012-01-12): After thinking about this and rereading the response from Stefan King on the TSVN dev mailing list to my question about DVCS, I realized or starting to think that this was really an issue for SVN. Think about my experiment below, what commands are TSVN? None, they are all from SVN. So I searched the SVN mailing list for "DVCS" (zilch for DVCS on the TSVN mailing list) and I saw this article posted 2 years ago, Subversion Vision and Roadmap Proposal, which has a pretty compelling argument for not making SVN a DVCS; in fact it even made me question DVCS in general. Then I thought, what is the main feature of DVCS that trumps a centralized repo, and I think it's offline commits. Searching for "offline commits" I found this post, On Offline Commits and Why They Should Be Piloted in TSVN. Funny because the strategy was very similar to my experiment, but I haven't found any other work toward this goal. Oh well - I've already migrated to git (see label: git going) and git svn makes that super easy.

Here is an experiment I did to see if TSVN could actually act like a DVCS. It's incomplete and disorganzed, but it did work

• Rationale:
• Does anyone really care or want DVCS for svn?
• especially when bzr, git and hg are already so good and can work with existing subversion repos!
• but it would be sad to see tsvn go
• there will still be many svn users
• is offline the biggest strength of DVCS?
• approach: 
• need clone, push and fetch similar to other DVCS, leverage existing svn methods, pilot in tsvn
• init a local repo
• use patches to clone the remote svn repo to the local repo
• work locally, commit locally
• push to remote repo, replay all local patches on remote repo
• fetch from remote repo, replay all remote patches on local repo
• it works, but a lot of overhead, and overly simplified
• notes: 
• get log, date and author info and pipe to file output
• svn propget -r <NUMBER/HEAD/etc.> -revprop svn:log
• svn propget -r <NUMBER/HEAD/etc.> -revprop svn:date
• svn propget -r <NUMBER/HEAD/etc.> -revprop svn:author
• create diffs of local and patch to remote and vice versa
• use export from remote to local
• svn log also prints log messages and pipe to output, instead of propget
• svn merge?
• svn help and svn help command