Re: Easy comparisons between related trunks, branches, and tags

Marc Sherman <msherman@projectile.ca> writes:
> Two properties are defined: svn:projectroot and svn:treeroot. No
> semantics are defined to the values of the properties; they're simply
> boolean flags, true if set, false if not.
>
> Each WC .svn directory stores two new pieces of information: the
> closest ancestor repository path in which the two properties are set.
> The treeroot must be a child of projectroot. The projectroot property
> is optional -- if not set on any ancestor directory, it defaults to
> the repository root.

Any time I hear about .svn directories storing Just One More piece of
information, a bell goes off in my head: "Okay, but is it versioned,
and if so, how will we make sure it gets outdate/updated correctly?"

In this case, the property itself is a regular versioned property set
on a directory. By asking descendant WCs to cache this property in a
special, non-versioned way, we're essentially implementing inherited
properties, but cheaply and with uncertain semantics :-).

I don't mean this as pejoratively as it sounds. Maybe the idea will
work out. But we should consider the edge cases: what happens to the
working copies when these properties disappear or change? How does a
working copy's cache behave if an "impossible" situation happens in
the repository such that multiple directories in a path chain have the
same property set?

Also, why are we caching them in the WC at all? Jim's original
proposal involved contacting the server and having it walk upward from
certain paths until it found certain properties. Marc's proposal
changes the properties and their meanings somewhat, *and* adds WC
caching to the picture. Couldn't we do just the former, but not the
latter?

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
> So, consider this example repository:
> 
> /
>    /projecta (P)
>      /trunk (T)
>      /branches
>        /1.x (T)
>        /2.x (T)
>      /tags
>        /1.0 (T)
>        /1.1 (T)
>        /1.2 (T)
>    /projectb (P)
>      /trunk (T)
>      /users
>        /msherman
>          /exp1 (T)
>        /jimb
>          /scratch (T)
>          /new
>            /try1 (T)
>            /try2 (T)
>      /releases
>        /1.1 (T)
> 
> We're in a working copy checked out from
> svn://repos/projecta/trunk/foo/bar.  We run:
>    svn diff -r +branches/2.x baz.txt
> 
> The working copy for this dir contains:
> svn:projectroot=svn://repos/projecta
> svn:treeroot=svn://repos/projecta/trunk
> 
> To construct the URL to compare baz.txt against, simply take the URL
> of BASE, and replace the leading svn:treeroot with
> svn:projectroot+"/"+"branches/2.x".
> 
> A more complex example: I'm in a working dir at
> svn://repos/projectb/users/msherman/exp1/foo/bar, and I want to diff
> against your try2 branch:
>    svn diff -r +users/jimb/new/try2 baz.txt
> 
> The working copy for this dir contains:
> svn:projectroot=svn://repos/projectb
> svn:treeroot=svn://repos/projectb/users/msherman/exp1
> 
> To get the URL to compare with, take
> svn://repos/projectb/users/msherman/exp1/foo/bar/baz.txt, and replace
> the leading treeroot with projectroot+branchparam, ie: replace
> "^svn://repos/projectb/users/msherman/exp1" with
> "svn://repos/projectb"+"/"+"users/jimb/new/try2", giving
> "svn://repos/projectb/users/jimb/new/try2/foo/bar/baz.txt"
> 
> Some error checking can be added to this:
> - When setting the properties, or on "svn cp" for branching/tagging,
> assert that the treeroot is not within another treeroot, and assert
> that the projectroot is not within another projectroot or treeroot
> - When doing the substitution to construct the second target URL,
> assert that the dir at svn:projectroot+"branches/2.x" is a treeroot
> within the same projectroot
> 
> This puts all the information about how to construct the paths in the
> location of the two properties; the user doesn't have to specify any
> paths or regexs in the properties at all.  All they have to do when
> setting up their repo is set the treeroot property on their trunk
> directory, and if required, set the projectroot (and it's only needed
> for multi-project repositories; it can be left out in the simple
> single-project repository setup).  Branching and tagging the trunk dir
> will propagate the treeroot property to the correct location, wherever
> it is.
> 
> What do you think?
> 
> - Marc
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
-- 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org