Ben:
You realize the branch directories don't actually take any
extra space, right?
They take a trivially small amount, right?
I have a peculiar usage scenario in mind and want to confirm
that svn supports it or understand why it doesn't.
The scenario might be named "always commit to branch", although that's
slightly to simplistic a name for it.
The idea is that instead of using:
/my-project/branch/....
in combination with a revid, I'll instead use:
/my-project/branch/base-0/....
for the initial import, and then each new "commit" will create
a new branch:
/my-project/branch/patch-1/...
/my-project/branch/patch-2/...
/my-project/branch/patch-3/...
The questions are:
(Just to confirm:) this will be space-efficient, right? The case of
each `patch-<n>' branch is roughly the same as the size of the
modified directories in that branch, plus the size of the file diffs?
(Not at all sure:) Can I create one of these patch-<N> directories
and commit all the tree rearrangements and file edits within it in a
single svn transaction? It's not critical that I be able to do so but
it could be helpful.
To make it clearer what I'm thinking, in case it isn't obvious --
The "branch names" i'd use ("/my-project/branch/patch-1") would be
chosen to be isomorphic to the arch global namespace of revisions.
The source trees would each contain a distinguished file
(e.g. "__LOG") that contains auto-generated merge history info for the
particular revision (along with user annotation). Each tree would
also have a subdirectory of log files of its ancestors. It might also
be worth (just for speed and simplicity) adding a file
(e.g. "__changes") that contains the "whole tree changeset" between
"patch-N" and its immediate ancestor (usually, but not always
"patch-(N-1)".
With that repository layout, it's a small-matter-of-scripting to (a)
build a bidirectional gateway between svn and arch (which means the
ability to exchange changes between distributed repositories in
controlled ways); (b) port the arch merging tools to svn.
Now, it gets a little weird here because suddenly you have two
different views on the history of a branch -- one that reflects the
ancestry of files and directories recorded in svn's db schema --
another that reflects the arch view of history. These aren't
perfectly isomorphic, but I don't think that's especially important.
Another weirdness has to do with modifying those patch-N trees. From
the "pure arch" perspective, they are each "write once" entities.
But now svn opens up a new possibility. Specifically, I can
create "patch-N" but not mark it as "final" --- while it isn't
"final", "patch-(N+1)" can't yet be created.
While "patch-N" isn't final, users can edit it in the usual svn
manner. So, instead of a single user creating "patch-N" -- the new
thing here is that you could have a team working on "patch-N" in the
CVS style. (This is why the atomicity question above isn't critical:
it may be more useful to not create these revisions atomically.)
"Can you hear me now?"
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 20:36:47 2003