Re: Subversion, decentralized version control, and the future

[Kyle McKay <ma...@tigris.org>]

On Jun 28, 2007, at 20:02, Karl Fogel <kf...@red-bean.com> wrote:
> From: Karl Fogel <kf...@red-bean.com>
> Date: June 28, 2007 16:56:46 PDT
> To: dev@subversion.tigris.org
> Subject: Subversion, decentralized version control, and the future.
> Reply-To: Karl Fogel <kf...@red-bean.com>

First I want to thank the Subversion developers for a fantastic  
version control system!  I have been following the subversion  
releases for some time now.  I use subversion for various projects,  
occasionally do some trivial hacking on it, have also given  
presentations on it at my workplace and have set up demonstration  
servers (auto versioning is great).  I expect that after the release  
of merge tracking support in 1.5 there will be substantial interest  
in trying out subversion on some real projects at my office (the  
current vcs we use provides automatic merge tracking and the lack of  
that feature is really a showstopper right now for trying Subversion  
-- svnmerge.py is just too limited for our use).

To get back to the topic of this thread, I would like to mention the  
features I wish Subversion had (which incidentally would make  
something like svk entirely unnecessary) and that I would like to see  
appear in a future release of Subversion:

----
1. Disjoint working copy administrative directories (.svn directories)

WHY: There are some situations, such as making changes to a working  
copy with certain tools, that step on .svn subdirectories and/or  
complain about them.  If you are unfortunate enough to run into this  
problem, there's really no good solution.

WHY NOT: There are situations where it's very nice to have the .svn  
directories be part of the working copy (easier to move, backup etc.  
as a unit).  So it would be nice if Subversion could have it both  
ways (user's choice).

Possible Implementation:

a) svn checkout grows a new "--disjoint" option.  This causes a entry  
to be added to the new ~/.subversion/disjointwc-hash file and a  
corresponding new subdirectory to be created in ~/.subversion/ 
disjointwc/.  The .svn directories that would have been located in  
the working copy are relocated to a directory tree with the same  
structure as the working copy (but without the working copy files)  
located in a subdirectory of ~/.subversion/disjointwc.  It's a simple  
matter to check the new disjointwc-hash file to find the  
appropriate .svn directory for working copy operations when a .svn  
directory is expected but not present.  (Hopefully the config file  
would also grow a means to make this the default if desired which  
implies support for a --no-disjoint option.)

b) svn info grows a new "--disjoint" option that basically lists the  
entries from disjointwc-hash in a nice, human-readable form.

c) svn kill is a new command that undoes an svn checkout (with  
various options).  It works on both normal and disjoint checkouts.   
When used on a disjoint checkout it removes the entry from the  
disjointwc-hash file and removes the corresponding tree of  
administrative directories under disjointwc/.

----
2. Cross-repository diffs.

WHY: There are many situations where this would be useful especially  
in distributed version control.

Possible Implementation:

a) svn diff command allows the source and destination to specify  
different repositories.  Internally if the client could request  
something like a tar.gz stream of a portion of a repository where the  
enumeration order was well-defined, it could simply open one of these  
streams to each of the two repositories and produce the diff on-the-fly.

----
3. Cross-repository copys

WHY: To support distributed version control.

Possible Implementation:

a) svn copy command allows the source and destination to specify  
different repositories.  This is really just an export and import  
without the inconvenience of having to store all the stuff on your  
local machine.  If svn import could take something like a tar.gz  
stream as input and svn export could produce something like a tar.gz  
stream for output the implementation would get a lot simpler.

b) svn copy needs to support this import/export shortcut so that the  
copy can be tracked for merge purposes.

----
4. Cross-repository merges and merge-tracking

WHY: To support distributed version control.

Possible Implementation:

a) svn merge command allows the source and destination to specify  
different repositories.  Internally the merge tracking data grows an  
optional repository UUID in front of the path.  If the UUID is not  
present it refers to the same repository that the merge tracking data  
is located in.

b) This may require an update to the merge algorithm to be most  
effective for distributed development (i.e. the Ancestry Set method  
mentioned in the merge tracking function spec. or something like what  
GNU arch uses.)

----
5. svnsync support for partial sync & repository creation

WHY: You may want part of a remote repository available for offline  
work, but don't want the overhead of everything.  Although svn  
checkout and subsequent svn update commands could be used, this is  
better because you get all the history and exact revision numbers  
available offline.  The addition of the "--create" option makes  
svnsync a one-stop shop for mirroring and avoids having to muck with  
hook scripts.

Possible Implementation:

a) svnsync initialize grows these new options:

"--create"   When specified, an implicit svnadmin create is done,  
revision property updates are enabled for the newly created  
repository and repository access is set to be read-only except for  
the svnsync program (the installed hook scripts could just check for  
a magic, exported environment variable set by svnsync).  Requires a  
file: URL for DEST_URL.  (There's no reason that the additional  
svnadmin create options couldn't be allowed as well as they are non- 
conflicting.)  Also intermediate directories are created in the  
DEST_URL path if they don't exist.

"--create-clone"  Same as --create except that after creation, the  
UUID of the newly created destination repository is changed to be the  
same as the SOURCE_URL repository UUID.  (The assumption here is that  
svnsync syncs the merge tracking data and the client could therefore  
perform offline merges with the svnsync'd clone interchangeably with  
the original SOURCE_URL since they would have the same UUID and  
revision numbers and the merge tracking info would therefore be  
interchangeable.)

"-r [--revision]"  When specified, revisions prior to this will not  
be synced (essentially they will be empty revisions, but when the  
specified beginning revision is reached and synchronized, it will  
actually contain all cumulative changes up to that point as a single  
change with an appropriate log message to indicate that).   
Alternatively @REV can be added to the SOURCE_URL instead of using -r.

SOURCE_URL allows a non-repository-root URL to be specified.  This is  
really already supported behind the scenes if you have limited read  
access to the source repository.  This addition simply exposes the  
same effective functionality directly to users (the non-synchronized  
portions of the source repository  are present in the destination  
repository path as empty directories so that relative repository  
paths remain the same between the source and destination even when  
only a portion of the source is being synchronized).

----
6. Support for shortcut file: URL specifications

WHY:  Wanting to create a local, for-use-by-oneself-only repository  
is a bit clumsy now as you have to choose a location and then deal  
with a likely long URL if it's somewhere in your user directory.   
Making this operation more convenient encourages use of local  
repositories.

Possible Implementation:

a) All svn commands accepting file: URLS are enhanced to understand a  
shortcut form that begins with "//".  The shortcut form "//foo" is  
translated to "file://$HOME/.subversion/localrepos/foo" and similarly  
"//foo/bar" is translated to "file://$HOME/.subversion/localrepos/foo/ 
bar" and so on.

b) svnsync is similarly enhanced

c) svnadmin is enhanced to understand the same shortcut form which is  
instead translated into a full absolute path rather than a file: URL.

----
So once you have all of the above, you can put it together like this:

svnsync initialize --create -r 25188 //collabnet/svn_trunk http:// 
svn.collab.net/repos/svn/trunk
svnsync synchronize //collabnet/svn_trunk
svn co http://svn.collab.net/repos/svn/branches/svn_enhancement

* head to beach *

svnadmin create //svn_enhancement
svn copy -m "local branch" //colabnet/svn_trunk //svn_enhancement
svn co --disjoint //svn_enhancement wc
cd wc

* implement super fancy subversion enhancement *

* visit local coffee shop with WiFi for lunch *

svnsync synchronize //collabnet/svn_trunk

* back to beach *

svn merge //collabnet/svn_trunk

* run fancy merge tool that doesn't know how to ignore .svn  
directories *

svn ci

* new EVDO data card starts working again *

cd ../svn_enhancement
svn up
svn merge //svn_enhancement
svn ci

----
I don't mean for the above to be put downs of Subversion.  I think  
Subversion is great.  I use it all the time.  There's just the odd  
little things that I bump into repeatedly and wish that Subversion  
could do and I thought the best way to communicate those was via the  
above with examples of how I imagined these things would work if  
Subversion did support them.

Thanks for your time.

Kyle McKay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org