Re: Subversion, decentralized version control, and the future
From: Kyle McKay <mackyle_at_tigris.org>
Date: 2007-07-02 05:20:20 CEST
On Jun 28, 2007, at 20:02, Karl Fogel <kfogel@red-bean.com> wrote:
First I want to thank the Subversion developers for a fantastic
To get back to the topic of this thread, I would like to mention the
---- 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.orgReceived on Mon Jul 2 05:20:24 2007 |
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.