Tom Lord <lord@emf.net> writes:
> 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?
Yes, exactly. If you create branch by doing an 'svn cp URL URL', then
you're effectively doing nothing but creating a new "hard link" in the
repository filesystem. When you start committing to the branch
directory, only changed files take up more space.
> (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.
Absolutely... a single transaction. Do it all in your working copy
first, then commit. Or operate on the repository directly with the
public svn_fs.h API: create, manipulate, and commit a transaction.
> 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.
Sure. You're imposing a structure.
> 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.
Impressive!
> 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.
Yes, this is a bit odd.
Your proposal is an interesting way of having two version control
systems "scratch each other's backs": Arch needs a cross-platform
repository storage mechanism, and Subversion needs a structure/system
for managing and distributing changesets.
> 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.
You're making my head spin! This is like double version control. The
collection of patches is one form of history, but now the patches
*themselves* have history as well?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 3 00:27:07 2003