You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jim Blandy <ji...@red-bean.com> on 2005/11/09 07:21:19 UTC
Easy comparisons between related trunks, branches, and tags
[Sorry for the duplicate. Karl pointed me at:
http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post]
On 08 Nov 2005 23:15:17 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> If "Easy branch comparisons" is what I think it is, Jim had a terrific
> idea about how to do that. I won't describe it here, but maybe this
> comment will spur him to do so :-).
I'm trying to outgrow my control-freak habits, so I'm forcing myself
to expose my tender sketch to y'all's stone-hearted criticism.
There's a part with an ellipsis (just one, not multiple ellipses) at
the end that shows the unraveled bit I haven't sorted out yet.
There is no code written after the big comment. I figured if I could
write the comment, the code would be easy.
$ cat /home/jimb/bin/svnp
#!/usr/bin/python
# This is a wrapper for 'svn', the Subversion command-line client,
# that implements a shorthand for referring to files in repository
# trees parallel to the tree in a working copy.
#
# Two directories are "parallel" if it makes sense to compare
# corresponding files in them. A trunk and a branch or tag taken from
# that trunk are parallel, as are two branches from the same trunk.
#
# Parallel directories often have a common ancestor in the repository;
# when this is so, comparison can recognize renamings and copies. But
# directories with no common ancestor can sometimes be parallel, too;
# for example, if you repeatedly import external releases of some
# tree, successive releases can often be usefully treated as parallel
# even though they have no common ancestor in the repository. In this
# case, saying that A and B are parallel simply means that for most
# any relative path R, it makes sense to compare A/R and B/R.
#
# The Subversion book recommends organizing a repository by having a
# 'trunk' directory for the main line of development, and sibling
# 'branches' and 'tags' directories whose contents are trees parallel
# to 'trunk'. This makes it easy to do things in your Subversion
# repository that resemble CVS's 'tag' and 'branch' operations.
#
# However, this organization is clumsy to work with. Given a working
# copy based on a branch, say, you will often want to compare its
# contents with the corresponding files or directories on the trunk;
# similarly for trunk-to-branch comparisons. Without some further
# structure, you must type out the full URL of the parallel directory
# in the repository:
#
# $ svn info
# ...
# URL: http://svn.red-bean.com/repos/project/branch/crazy-idea/subdir
# ...
# $ cd subdir
# $ svn diff --old . --new http://svn.red-bean.com/repos/project/trunk\
# /subdir
#
# (I can't even fit the command on one line in this documentation, and
# I'm not using unrealistic filenames or hostnames.)
#
# There is a lot of redundancy in this command. In the common case:
#
# - We make intra-repository comparisons. You shouldn't need to
# re-type the host name and repository path (here,
# 'http://svn.red-bean.com/repos').
#
# - We make intra-project comparisons. You shouldn't need to re-type
# the project name (here, 'project').
#
# - We compare parallel directories within parallel trees. You
# shouldn't need to re-type the subdirectory (here, 'subdir'), since
# it's apparent from your working directory.
#
# Omitting these pieces from the diff command above, we get:
#
# $ svn diff --old . --new trunk
#
# But we still need some indication that 'trunk' is not a local
# relative filename; the presence of the leading URL scheme 'http:'
# used to do this, but that's gone now. For the sake of argument,
# we'll put a '+' in its place:
#
# $ svn diff --old . --new +trunk
#
# (You could argue that --old and --new are redundant, too, but those
# resolve ambiguities in the meaning of the 'svn diff' command
# unrelated to the repository structure. We'll leave those in place
# for now.)
#
# To compare a trunk-based working copy with a particular branch, one
# should be able to type something like:
#
# $ svn diff --old . --new +branch/crazy-idea
#
# There are few more rights we expect:
#
# - You shouldn't need to explain to Subversion the relative positions
# of your 'trunk', 'tags', and 'branches' directories. These were
# established when you first arranged your repository, and are
# essentially static.
#
# - You shouldn't have to distribute some sort of abbreviation list to
# your users to make all this work. You should be able to put the
# needed information in the repository, and always have the current
# data available automatically. (That is, config file tweaking is
# out.)
#
# This wrapper implements the above syntax, based on guidance from
# properties set on directories in the repository. If you use 'svnp'
# instead of 'svn', we will expand arguments of the form
# '+KIND/SUBDIR' (where KIND contains no slashes) according the
# following rules, and pass the resulting argument list on to 'svn':
#
# - First, assume that our current working directory is based on the
# repository path BASE.
#
# - Find the lowest parent of BASE (in the repository) that has a
# property named 'svnp:parallel:KIND'. (If BASE itself has such a
# property, then use BASE.) Call this parent directory PARENT, so
# BASE is PARENT/RELATIVEBASE for some RELATIVEBASE (possibly '.').
# Call the property's value KINDDIR.
#
# - Replace the '+KIND/SUBDIR' argument with the string
# 'KINDDIR/SUBDIR/RELATIVEBASE'.
# ... But how do you eliminate branch names in
# 'branches/branchname/subdirs'? If there's deep hierarchy under
# 'branches', you don't know how many components to drop to find the
# trunk, but keep subdirs.
$
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Alan Barrett <ap...@cequrux.com>.
On Wed, 09 Nov 2005, Kevin Puetz wrote:
> I punted both of those issues by making the user say, ala patch, how many
> path components to whack off the front (essentially either 1 (/trunk), 2
> (/{branches,tags}/*), or perhaps 3 (if you have branches or tags sorted
> into groupings).
My concern is that it doesn't seem to cope easily with the case where
there are several directory levels between the repository root and the
{trunk,branches,tags} level. A real solution will need to work easily
in a repository that has URLs like
svn://long.name.of.server/long/path/to/repository/long/path/to/project/branches/branchgroup/branchname/long/path/to/subdir/file
Sorry, but as a user, I want to be able to do
diff -r branches/othergroup/otherbranch filename
or something that involves approximately the same amount
of typing as that. I don't want to have to remember or
calculate a number of path components to drop or retain,
and I don't want to have to type any part of either
"svn://long.name.of.server/long/path/to/repository/long/path/to/project"
or "long/path/to/subdir".
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
I'll admit, I'm less than fond of patch's -p option. It has always seemed to
me like a workaround for the absence of a clear convention on how tree
patches should work. That is, if diff and patch had been designed together
with entire trees in mind, you'd never need -p; you'd just think that whole
idea was weird.
In the Subversion context, if I'm in some subdirectory of tree A, I should
be able to do comparisons in the corresponding subdirectory of some parallel
tree B without counting parents.
Re: Easy comparisons between related trunks, branches, and tags
Posted by Kevin Puetz <pu...@puetzk.org>.
Alan Barrett wrote:
> On Tue, 08 Nov 2005, Jim Blandy wrote:
>> # Two directories are "parallel" if it makes sense to compare
>> # corresponding files in them. A trunk and a branch or tag taken from
>> # that trunk are parallel, as are two branches from the same trunk.
>
> Yes, this definition of "parallel" is exactly the right way of looking
> at the problem.
>
> I think that Greg's idea of transformation rules required the two
> directories to have a common ancestor (at which there would be a dirprop
> describing the transformation rule), whereas your idea doesn't need
> a common ancestor (placing the necessary dirprops at the "trunk" or
> "branches/foobranch" or "vendor/release" level, not at the "project"
> level).
>
> I noticed two unsolved problems: If several branches are each declared
> as parallel to the trunk, how do we know that the branches are also
> parallel to each other? And how do we know how many directory
> components are part of the branch specifier, as opposed to part of the
> directory within the branch?
>
> --apb (Alan Barrett)
This approach is (somewhat) similar to the strawman I was sketching in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=107942 (which
was a crossposted reply to gcc, so the subject may not have gotten very
many people to look at it).
I punted both of those issues by making the user say, ala patch, how many
path components to whack off the front (essentially either 1 (/trunk), 2
(/{branches,tags}/*), or perhaps 3 (if you have branches or tags sorted
into groupings).
The places I was stuck on were:
I was expanding one option into a value for old and new, so I didn't have a
good way to specify the distinction between '.' and URI@base as the 'local'
copy
I also didn't have anything that felt good for reversing the arguments.
Continuing to use separate --old and --new, but having a special syntax that
references the other one solves both of those, I think...
So, combining the two strawmen, we'd have something like -N:path as a valid
form for specifying --old and --new. Using an option-like syntax for the
argument to --old/new feels agreeably special - filenames that start with
'-' already need escaping with ./-file in many cases. It also feels pretty
natural to let -N:* remove N of something
To spec this a little tighter, we'd look at both old and new, and if both
are the special 'parallel' syntax (start with -), that's either an error or
they are both relative to cwd. The former has the advantage of (slightly)
less magic, the latter would make it easy to compare two tags, neither of
which is the wc url but both of which are relative to it. That could be
handy for merge... I think I'm leaning toward the latter. Otherwise, the
relative one is computed against the one that specs an absolute URL (which
coudl be an explicit absolute URL, or a wc path of any sort)
Anyway, to an example:
# svn diff --old . --new -1:/branches/foo@peg bar.c baz.c
Once we've picked an absolute path, that's the base for generating the
relative ones. So in this case our base is '.'. Then we need to get the URL
and repository root from the absolute one:
# svn info . (the absolute url)
URL: svn://root/trunk/subdir
Repository-Root: svn://root
whack Repository-root off the front of URL, and seperate a peg if any:
/trunk/subdir @peg
prune the specified number of components (1, in this case) and replace them
with the prefix, and reattach the peg
/branches/foo /subdir @peg
giving
# svn diff --old . --new svn://root/branches/foo/subdir@peg bar.c baz.c
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Julian Foad <ju...@btopenworld.com>.
Jim Blandy wrote:
> Here's a revision of my original suggestion that handles deep branch
> directories nicely. Skip down to 'we will expand arguments'; not much
> above that has changed.
[...]
> # - First, assume that our current working directory is based on the
> # repository path BASE.
> #
> # - Find the lowest parent of BASE that has a property named
> # 'svnp:parallel-root'. (The value of this property must be '.';
> # don't worry about that for now.) This marks the root of a tree
> # which has parallel trees elsewhere. Call this directory PROOT.
> # Since it's a parent of BASE, there's some RELBASE such that
> # PROOT/RELBASE is BASE. PROOT may be BASE itself, in which case
> # RELBASE is '.'.
> #
> # - Find the lowest parent of RELBASE that has a property named
> # 'svnp:parallel:KIND'. Its value should be an absolute repository
> # path; call that KINDROOT.
I believe that should have said, "Find the lowest parent of PROOT that ...".
> # - Replace the '+KIND[/SUBDIR]' argument with the string
> # 'KINDROOT/SUBDIR/RELBASE'. (Use '.' for SUBDIR if it's absent, or
> # just omit that path element altogether.)
> #
> # So, the root of every parallel tree needs to be marked with
> # 'svnp:parallel-root', and at some parent directory common to all
> # your parallel trees you need a bunch of 'svnp:parallel:KIND'
> # properties.
Your plan is looking promising.
The biggest restriction I see is that it only supports one level of branches.
By that I mean that for any given file F, the branches that contain F will all
have been copies of the same (project-root) node N. We, the Subversion
developer community, typically only create branches of a "whole project", but
sometimes a "whole project" is not as identifiable as it sounds. For example,
the documentation team might like to create a branch of just a "doc" sub-tree
for adding mark-up, so:
/trunk/proj1 --> /branches/proj1/release/v1.0.x
/trunk/proj1/blah/doc --> /branches/proj1/doc/add-markup
Though we might recommend against it, it's inevitable that some people will
need, and some will use, multi-level branches such as these. Any new feature
for addressing branches must support these to some reasonable extent because it
is in these more complex projects that people stand to gain most from the feature.
Can you extend your proposal to make these complexities _possible_ without
necessarily being as easy as the basic scenario? Part of this extension would
presumably be something like "If the first properties found when walking up the
tree don't lead to finding a branch of the given name, then walk further up and
try again."
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Michael Sweet <mi...@easysw.com>.
Jim Blandy wrote:
>> Sure -- I was delving into the cache-invalidation strategy, that's
>> all. (It would be more constructive if I tried to come up with that
>> strategy myself, but I'd prefer to jut my lip poutily and make Marc do
>> it.)
>
> Any time the base revision of the directory changes, you need to
> refresh the cached value. If the base revision hasn't changed, the
> properties on the directory and its parents can't have changed.
As I mentioned in a separate thread (for the log template stuff),
using the cached property value until the next update is a valid
design/mode of operation and would be consistent with how the rest
of the WC stuff works today.
IOW, "svn diff" doesn't need to check the validity of the cache, it
can depend on "svn update" to do the work for it.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by kf...@collab.net.
Jim Blandy <ji...@red-bean.com> writes:
> > Sure -- I was delving into the cache-invalidation strategy, that's
> > all. (It would be more constructive if I tried to come up with that
> > strategy myself, but I'd prefer to jut my lip poutily and make Marc do
> > it.)
>
> Any time the base revision of the directory changes, you need to
> refresh the cached value. If the base revision hasn't changed, the
> properties on the directory and its parents can't have changed.
Yup, I think that's it. It's simpler than I thought, fortunately!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
> Sure -- I was delving into the cache-invalidation strategy, that's
> all. (It would be more constructive if I tried to come up with that
> strategy myself, but I'd prefer to jut my lip poutily and make Marc do
> it.)
Any time the base revision of the directory changes, you need to
refresh the cached value. If the base revision hasn't changed, the
properties on the directory and its parents can't have changed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
kfogel@collab.net wrote:
>
> The so-called impossible situation is if you have a chain of
> directories in which two or more both have the P or T property, e.g.:
>
> /myproj/branches/experimental/skunkworks/mybranch_of_myproj/...
> `--- T ---' `-- T ---'
>
> What if both 'experimental' and 'skunkworks' have the T property?
> Marc stipulated we'd have a rule saying that should never happen:
>
>
>>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
As I mentioned in another message, I now agree that this should only be
reported as an error when a + expansion is attempted either from within
"skunkworks", or referring to "skunkworks". The svn cp or propset that
got us there should not cause an error, though it might be useful to
have it warn.
> I think the valuable insight Marc and you have led us to is that what
> we want is the *effect* of inherited properties, not necessarily
> inherited properties themselves.
>
> Previous discussions concentrated on ways to get directory D's
> property reflected in D's descendents *as a regular property*, and we
> ran into all sorts of hairy questions that way. But if we disentangle
> the inherited properties from the regular properties, and put the
> inherited in their own cache, maybe a lot of those problems go away.
I think they might. It would also allow that cache to include the extra
info needed for this feature, ie: from which ancestor is the property
inherited. Additionally, it would allow easy implementation of erroring
out on "svn propdel/propedit" of an inherited property.
I think it would be a very good idea for any thinking/work on inherited
properties to happen in, or on an experimental branch off of, the
propcaching branch, to avoid undoing any of the excellent work being
done there.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 12 Nov 2005 17:24:16 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> Jim Blandy <ji...@red-bean.com> writes:
> > the property up to the root of the revision. If you cache it
> > client-side, then you've got a cache whose coherency you need to
> > maintain, but correct caches should never affect the semantics of a
> > feature.
>
> Sure -- I was delving into the cache-invalidation strategy, that's
> all. (It would be more constructive if I tried to come up with that
> strategy myself, but I'd prefer to jut my lip poutily and make Marc do
> it.)
I thought you were uncertain about what the visible semantics would
be. I agree that there are interesting questions in the
implementation of a correct cache. But the desired semantics here are
very simple: we have 'svn propget --search-up'. The cache hopefully
makes it fast, and makes it work off-line, but should have no effect
on the meaning of the operation.
> The so-called impossible situation is if you have a chain of
> directories in which two or more both have the P or T property, e.g.:
>
> /myproj/branches/experimental/skunkworks/mybranch_of_myproj/...
> `--- T ---' `-- T ---'
>
> What if both 'experimental' and 'skunkworks' have the T property?
> Marc stipulated we'd have a rule saying that should never happen:
>
> > 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
>
> That's fine, however, there will probably still be ways to cause it to
> happen.
I certainly agree. I want to help people keep track of what they're
trying to do and warn about things that look suspicious, but I'm not
in favor of actually restricting Subversion's behavior in the presence
of these properties. (Of course, if the user actually set some flag
saying "Please prevent me from breaking proper structure" --- like
using -Werror in GCC --- then that would be okay.)
If we simply explain in the documentation how + expansion works, in
terms of searching upwards for directory properties, users can see for
themselves what behavior ill-formed properties will cause.
> However, I'd guess that for the sake of other properties we might want
> to cache, the better solution would to always cache the deepest
> property, see below...
That's what it adds up to.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by kf...@collab.net.
Jim Blandy <ji...@red-bean.com> writes:
> the property up to the root of the revision. If you cache it
> client-side, then you've got a cache whose coherency you need to
> maintain, but correct caches should never affect the semantics of a
> feature.
Sure -- I was delving into the cache-invalidation strategy, that's
all. (It would be more constructive if I tried to come up with that
strategy myself, but I'd prefer to jut my lip poutily and make Marc do
it.)
> > 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?
>
> There is no "impossible situation" involved here that I can see.
The so-called impossible situation is if you have a chain of
directories in which two or more both have the P or T property, e.g.:
/myproj/branches/experimental/skunkworks/mybranch_of_myproj/...
`--- T ---' `-- T ---'
What if both 'experimental' and 'skunkworks' have the T property?
Marc stipulated we'd have a rule saying that should never happen:
> 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
That's fine, however, there will probably still be ways to cause it to
happen. I just wanted to know what the WC caching semantics would be
in that case. We can define it as an error condition and say the
cache is undefined, if we want.
However, I'd guess that for the sake of other properties we might want
to cache, the better solution would to always cache the deepest
property, see below...
> Yep. I think the WC caching, without some kind of general framework
> for invalidating such caches, is a tar baby for this particular
> feature. But if we solve it for log templates, then the parallel tree
> abbreviations would benefit.
Definitely! Inherited properties are a panacea for a lot of features:
autoprop configurations, log message templates, this new
find-related-branches-easily idea, svn:ignore propagation. I'm
probably forgetting others.
If we can get this working ("this" being "wc-side caching of certain
properties found in an N-parent of the current directory"), then we
might have a very big win on our hands :-).
I think the valuable insight Marc and you have led us to is that what
we want is the *effect* of inherited properties, not necessarily
inherited properties themselves.
Previous discussions concentrated on ways to get directory D's
property reflected in D's descendents *as a regular property*, and we
ran into all sorts of hairy questions that way. But if we disentangle
the inherited properties from the regular properties, and put the
inherited in their own cache, maybe a lot of those problems go away.
I'm on the verge of proposing a full description of how that cache
could be maintained, but I can tell I need to let it stew for a bit
longer... However, please don't let that stop you (you or Marc or
anyone else, that is) from posting such a description yourself. I
don't think I'd come up with anything better than what you would.
Let's try to avoid adding new files in the .svn area, though :-).
Daniel Berlin is throwing his heart into reducing the file/inode
penalty in there; we don't want to undo this good work. Having the
cache in, say, .svn/entries would be fine, IMHO.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 12 Nov 2005 14:50:18 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> 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?"
The real info is the presence of properties marking parallel root
directories and the project root directory. If you cache that
somewhere for speed or off-line behavior, that's your own business.
Personally, since the whole point of this info is for doing
inter-branch comparisons, I don't see a lot of point in caching it in
the working copy.
> 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 :-).
Let's presume we were going to cache the values in the WC, just for
the sake of generality. I don't see what you mean by "non-versioned"
or "uncertain". The official semantics are that you do a search for
the property up to the root of the revision. If you cache it
client-side, then you've got a cache whose coherency you need to
maintain, but correct caches should never affect the semantics of a
feature.
> But we should consider the edge cases: what happens to the
> working copies when these properties disappear or change?
A WC directory is always based on a particular path in a particular
revision. You scan up that directory's parents in that revision.
There's nothing edge-casey about this.
> 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?
There is no "impossible situation" involved here that I can see.
> 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?
Yep. I think the WC caching, without some kind of general framework
for invalidating such caches, is a tar baby for this particular
feature. But if we solve it for log templates, then the parallel tree
abbreviations would benefit.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/13/05, Alan Barrett <ap...@cequrux.com> wrote:
> So, if I understand correctly, svn:treeroot should never be set on both
> a directory and any of its ancestors. This would make it difficult to
> do something that's easy and common with CVS: have some branches that
> affect the entire project, and other branches that affect only part of
> the project. For example, in NetBSD, some branches affect the entire
> "src" tree (userland and kernel), some affect only "src/sys" (kernel),
> some affect src + xsrc, and others do something else.
My last proposal had a way to deal with these, but I didn't write it
up. The comments I wrote mentioned that the value of
svnp:parallel-root should always be ".", but didn't explain further.
To create a branch of only a portion of the project, say
"subdir1/subdir2", you would set the svnp:parallel-root property's
value to "subdir1/subdir2"; that could then be inserted/removed as
needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 12 Nov 2005, Marc Sherman wrote:
> 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.
So, if I understand correctly, svn:treeroot should never be set on both
a directory and any of its ancestors. This would make it difficult to
do something that's easy and common with CVS: have some branches that
affect the entire project, and other branches that affect only part of
the project. For example, in NetBSD, some branches affect the entire
"src" tree (userland and kernel), some affect only "src/sys" (kernel),
some affect src + xsrc, and others do something else.
-apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
Jim Blandy wrote:
>
> This proposal is the simplest I've seen so far that addresses the
> problem for most traditionally-structured repositories. If you've got
> your parallel trees scattered around more, it won't work as well, but
> maybe the answer is "don't do that".
You've alluded to this failure mode a few times, and I've been wracking
my brain trying to visualize it; can you give me an example, please?
> The error-checking is a definitely a good suggestion. However, we
> should make sure the error checking only happens when someone actually
> uses the '+' syntax; we don't want to constrain how people use the
> repository if they're not interested in our abbreviation. I think
> that simply means doing the checks when we expand it.
Yes, having read the discussion of this in the thread, I agree; the
assertions I suggest should only happen when a + expansion is actually
used, not on "svn cp" or "svn propset". A warning might be appropriate
on the latter, but even that might be too much.
> I'd like to hear how other folks feel about this proposal. Is it
> general enough? Does it restrict people from doing valuable things?
Of course this thread would finally take off on the first day I'm off
line all day... :) I've got a lot of reading to catch up on now.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Alan Barrett <ap...@cequrux.com>.
On Sun, 13 Nov 2005, Jim Blandy wrote:
> On 11/13/05, Alan Barrett <ap...@cequrux.com> wrote:
> > It's not as general as Greg's rewrite rules.
>
> Do you have a pointer handy to a thread explaining Greg's rewrite rules?
The original proposal is at
http://svn.haxx.se/dev/archive-2005-05/1367.shtml.
A recent discussion behins at
http://svn.haxx.se/dev/archive-2005-11/0154.shtml.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Christian Stork <cs...@ics.uci.edu>.
On Sun, Nov 13, 2005 at 06:36:23PM +0200, Alan Barrett wrote:
> On Sun, 13 Nov 2005, Christian Stork wrote:
...
> > The projectrule property could contain a mapping from nicknames to
> > subdirs, eg:
> > crazy branches/users/jim/experimental/crazy
> > beta branches/beta
> > a branches/alpha
> If you add a wildcard syntax, so that we could say
> rel-* tags/releases/rel-$1
> with the right hand side "$1" referring to whatever was matched by
> the left hand side "*", then I think you have all the capabilities of
> the rewrite rules proposal. If the nickname rules are optional, and
> everything works (just without nicknames) in the presence of only the
> projectroot and treeroot properties, then you also have something that's
> easier to set up (in common simple cases) than rewrite rules. I think
> we have a winner.
Indeed, looks nice. :-) The only caveat introduced by wildcards that I
can think of are accidental nickname clashes. For example:
* branches/users/jim/experimental/*
* branches/users/chris/well-thought-out/*
seems like a really bad idea. It is the users responsibility to prevent
name clashes:
jim-* branches/users/jim/experimental/*
chris-* branches/users/chris/well-thought-out/*
Of course, guaranteed overlap-free matching could be automatically
verified, but now we are getting into the land of over-engineering.
Hmm, maybe a workable solution would be if subversion complains or
errors out if it detects an ambiguity when used. So, as long as the
expansion for the stars in the first example don't collide everythning
is fine.
Also note, that if we deem wildcard patterns worthy for nickname
determination, than we have a good reason to choose this proposal over
the conceptually simpler (but maybe practically more annoying) "svn ls"
idea.
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Alan Barrett <ap...@cequrux.com>.
On Sun, 13 Nov 2005, Christian Stork wrote:
> > > The ability to have branches that cover only a subset of the project;
>
> > Jim's suggested a way to expand the proposal to cover this; the value of
> > the treeroot property is the subpath that's branched. For trees
> > branched from the root, it's empty.
>
> I have to say that Jim's suggestion does not seem to overly complicate
> things, in fact it seems like a clean generalization of your proposal.
> And since it does cover some significant uses of branches it seems worth
> it.
Yes, it looks good to me too.
> > > The ability to map from short nicknames to longer branch names (e.g.
> > > a rewrite rule could map from "B#foo" to "branches/gcc-foo-branch",
> > > while the projectroot+treeroot proposal would require the user to
> > > specify '+branches/gcc-foo-branch").
>
> I think I have a nice generalization of your proposal to achieve these
> short branch nicknames. (If that is desirable as you doubt below is
> another question.)
>
> The projectrule property could contain a mapping from nicknames to
> subdirs, eg:
>
> crazy branches/users/jim/experimental/crazy
> beta branches/beta
> a branches/alpha
If you add a wildcard syntax, so that we could say
rel-* tags/releases/rel-$1
with the right hand side "$1" referring to whatever was matched by
the left hand side "*", then I think you have all the capabilities of
the rewrite rules proposal. If the nickname rules are optional, and
everything works (just without nicknames) in the presence of only the
projectroot and treeroot properties, then you also have something that's
easier to set up (in common simple cases) than rewrite rules. I think
we have a winner.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mailing list ettiquette (was Re: Easy comparisons between related trunks, branches, and tags)
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Nov 13, 2005 at 04:28:17PM -0500, Marc Sherman wrote:
> Greg Hudson wrote:
> >I woke up today to two messages from Alan, three from Jim, and four from
> >Marc Sherman on this thread. I can't fault Alan, but Jim and Marc,
> >please read the whole thread before sending off replies? When dev
> >threads grow complex like this, we need people to force them into a more
> >linear structure. Outside readers cannot follow them if the tree
> >structure grows too complex. Thanks.
>
> Sorry. I did read the entire thread before writing any of my replies,
> and tried to limit the replies to specific points that I wanted to
> respond to. Would it be preferable in the future for me to exerpt all
> those quotes into a single large reply message? I considered doing
> that, but it breaks threading so I thought the replies I sent was a
> better way to do it.
I think most people thread based on the topic, not this-message-replied-
to-that-message. So your four messages create a scattershot across the
"logical thread". Lots of little bitty replies make it harder to see
where the whole thread is going, and harder to deal with responding to
open issues and concerns.
So yes: ideally, you'd pull together a bunch of little bits and reply
to them as a coherent whole. Possibly point-by-point, but at least the
next guy can see everything in one place and respond to any portions
they care about.
Now, when a sub-thread truly diverges, then it is appropriate to
change the subject (including a "was:", much like what happened here).
That let's people know that it really is a whole separate topic,
rather than a piece of the original thread.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Christian Stork <cs...@ics.uci.edu>.
On Sun, Nov 13, 2005 at 08:09:54AM -0500, Marc Sherman wrote:
> Alan Barrett wrote:
> >It's not as general as Greg's rewrite rules. Two features that rewrite
> >rules could offer that are missing from the projectroot+treeroot
> >proposal are:
> > The ability to have branches that cover only a subset of the project;
> Jim's suggested a way to expand the proposal to cover this; the value of
> the treeroot property is the subpath that's branched. For trees
> branched from the root, it's empty.
I have to say that Jim's suggestion does not seem to overly complicate
things, in fact it seems like a clean generalization of your proposal.
And since it does cover some significant uses of branches it seems worth
it.
> > The ability to map from short nicknames to longer branch names (e.g.
> > a rewrite rule could map from "B#foo" to "branches/gcc-foo-branch",
> > while the projectroot+treeroot proposal would require the user to
> > specify '+branches/gcc-foo-branch").
I think I have a nice generalization of your proposal to achieve these
short branch nicknames. (If that is desirable as you doubt below is
another question.)
The projectrule property could contain a mapping from nicknames to
subdirs, eg:
crazy branches/users/jim/experimental/crazy
beta branches/beta
a branches/alpha
In contrast to decorating the treeroots with nickname props this
prevents inefficient searches for the actual tree location and it makes
naming conflicts immediatly apparent since they happen in a single file.
> This, on the other hand, I explicitly didn't want to include in my
> proposal. IMO, general aliasing should be the province of something
> like "svn ln". If the alias is useful for "svn diff", it should be
> useful for "svn co" as well, and a rewrite rule doesn't help there.
I agree that subversion-managed intra-repository links are conceptually
much nicer (eg they could immediatly flag when a "nickname branch" turns
stale). OTOH, I don't know if I'd like my project root dir littered
with all current nickname links...
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/13/05, Alan Barrett <ap...@cequrux.com> wrote:
> It's not as general as Greg's rewrite rules.
Do you have a pointer handy to a thread explaining Greg's rewrite rules?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/13/05, Alan Barrett <ap...@cequrux.com> wrote:
> > If you've got your parallel trees scattered around more, it won't work
> > as well, but maybe the answer is "don't do that".
>
> "Don't do that" is not very nice advice to people trying to migrate from
> CVS to subversion, because they may already have branches that don't
> cover the entire project. However, perhaps some cleverness (and more
> complex configuration capabilities) in cvs2svn would be good enough.
Okay. The hairier proposal that Marc's was a simplification of
doesn't have this restriction.
> The ability to map from short nicknames to longer branch names (e.g.
> a rewrite rule could map from "B#foo" to "branches/gcc-foo-branch",
> while the projectroot+treeroot proposal would require the user to
> specify '+branches/gcc-foo-branch").
The hairier proposal doesn't do this. (CVS doesn't either, if we're
concerned with appeasing reluctant converts.)
> From a syntax point of view, adding "+" as a reserved character at the
> start of a path seems less safe than adding "#" as a reserved character
> in a revision name.
The syntax is very much a straw man. The SVNP Python script is just
something to help out the GCC folks until we can make things work
directly in Subversion, and the + syntax works well with the wrapper
script idea, since it saves me from having to parse Subversion
options.
I'm still trying to get to the point where I feel like I really
understand what the diff options mean (blush), and that seems like a
prerequisite to proposing further command-line syntax. It may be that
neither --old/--new nor -r is the right place to put these names.
What I'm concerned with at this point is representing the needed
information in the repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mailing list ettiquette (was Re: Easy comparisons between related trunks, branches, and tags)
Posted by Molle Bestefich <mo...@gmail.com>.
Marc Sherman wrote:
> Would it be preferable in the future for me to exerpt all
> those quotes into a single large reply message?
That usually makes it easier to grasp what you're trying to convey, imho..
> I considered doing that, but it breaks threading so I
> thought the replies I sent was a better way to do it.
RFC 2822:
The "In-Reply-To:" field will contain the contents of the "Message-
ID:" field of the message to which this one is a reply (the "parent
message"). If there is more than one parent message, then the "In-
Reply-To:" field will contain the contents of all of the parents'
"Message-ID:" fields. If there is no "Message-ID:" field in any of
the parent messages, then the new message will have no "In-Reply-To:"
field.
So optimally, I guess you should bug those who make your e-mail
application to make an "include inline reply to <this> message also"
button, which would preserve threading as mentioned in above rfc *and*
allow you to keep the number of messages down :-).
Maybe worth a feature request for google mail, since aside from this
they've got excellent conversation threading already...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
Alan Barrett wrote:
>
> It's not as general as Greg's rewrite rules. Two features that rewrite
> rules could offer that are missing from the projectroot+treeroot
> proposal are:
>
> The ability to have branches that cover only a subset of the project;
Jim's suggested a way to expand the proposal to cover this; the value of
the treeroot property is the subpath that's branched. For trees
branched from the root, it's empty.
> The ability to map from short nicknames to longer branch names (e.g.
> a rewrite rule could map from "B#foo" to "branches/gcc-foo-branch",
> while the projectroot+treeroot proposal would require the user to
> specify '+branches/gcc-foo-branch").
This, on the other hand, I explicitly didn't want to include in my
proposal. IMO, general aliasing should be the province of something
like "svn ln". If the alias is useful for "svn diff", it should be
useful for "svn co" as well, and a rewrite rule doesn't help there.
> From a syntax point of view, adding "+" as a reserved character at the
> start of a path seems less safe than adding "#" as a reserved character
> in a revision name.
Note that I was using -r +..., not --old +.... Like Jim, though, I was
definitely concentrating on the behaviour I was after, not the syntax.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Mailing list ettiquette (was Re: Easy comparisons between related
trunks, branches, and tags)
Posted by Marc Sherman <ms...@projectile.ca>.
Greg Hudson wrote:
> I woke up today to two messages from Alan, three from Jim, and four from
> Marc Sherman on this thread. I can't fault Alan, but Jim and Marc,
> please read the whole thread before sending off replies? When dev
> threads grow complex like this, we need people to force them into a more
> linear structure. Outside readers cannot follow them if the tree
> structure grows too complex. Thanks.
Sorry. I did read the entire thread before writing any of my replies,
and tried to limit the replies to specific points that I wanted to
respond to. Would it be preferable in the future for me to exerpt all
those quotes into a single large reply message? I considered doing
that, but it breaks threading so I thought the replies I sent was a
better way to do it.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Greg Hudson <gh...@MIT.EDU>.
I woke up today to two messages from Alan, three from Jim, and four from
Marc Sherman on this thread. I can't fault Alan, but Jim and Marc,
please read the whole thread before sending off replies? When dev
threads grow complex like this, we need people to force them into a more
linear structure. Outside readers cannot follow them if the tree
structure grows too complex. Thanks.
On Sun, 2005-11-13 at 10:46 +0200, Alan Barrett wrote:
> > I'd like to hear how other folks feel about this proposal. Is it
> > general enough? Does it restrict people from doing valuable things?
I think it's nice and elegant, insofar as when you create a branch, the
svn:treeroot property comes along for the ride, and does not need to be
modified. My impression of Jim's proposal (which, sadly, I have not
fully wrapped my head around) is that you'd have to do a bunch of
property-fiddling every time you create a new branch.
But I have another proposal which I think has that nice property as
well, and some other advantages.
> It's not as general as Greg's rewrite rules. Two features that rewrite
> rules could offer that are missing from the projectroot+treeroot
> proposal are:
I threw out that as a straw man in
http://svn.haxx.se/dev/archive-2005-05/1367.shtml .
I'm no longer enamored of that proposal, because I think it's too
general, and users would not be able to understand it without a lot of
effort. That's probably also true of Jim's proposal, and to some extent
Marc's. I now believe the client (though not the server) should
understand the concept of trunk, branches, and tags.
Here's the general idea: a directory property svn:ttb contains the FS
paths of the trunk, tags, and branches directories. The value might
look like "/trunk /tags /branches"; perhaps that could even be the
default, although that's a little dangerous. (Quoting issues might push
us in the direction of three separate properties, svn:trunk, svn:tags,
and svn:branches. Whatever.) Obviously, this is a property we'd like
to have apply to subdirectories somehow, as in the other proposals.
I'm not going to address the client syntax for using this information,
though as I've said before, I still like the idea of generalizing -r so
that a revision specifier can change the URL as well as set the revision
number.
>> If you've got your parallel trees scattered around more, it won't
>> work as well, but maybe the answer is "don't do that".
> "Don't do that" is not very nice advice to people trying to migrate
> from CVS to subversion, because they may already have branches that
> don't cover the entire project. However, perhaps some cleverness (and
> more complex configuration capabilities) in cvs2svn would be good
> enough.
I think it's better to get everyone to a place where they can use a
simple, elegant feature than it is to make a feature everyone can use
but no one can understand.
With my svn:ttb proposal, you could create a branch or tag off part of
the tree which applies to part of the tree and set svn:ttb on that
branch to "/trunk/src/sys /kerneltags /kernelbranches", but it would
only work one way. You could go into /kernelbranches/foo and easily
diff against the trunk, but you couldn't go into /trunk/src/sys and
easily diff against a kernel branch. We could extend the property
syntax so that there are multiple places to look for branches off of
different parts of the tree, but then nobody would understand the
feature any more.
Better, I think, to tell people to move the kernel branches
to /branches/foo/src/sys, so that a kernel branch looks like a branch of
the entire tree with most of the tree missing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 12 Nov 2005, Jim Blandy wrote:
> [Marc Sherman's projectroot+treeroot proposal] is the
> simplest I've seen so far that addresses the problem for most
> traditionally-structured repositories.
Agreed.
> If you've got your parallel trees scattered around more, it won't work
> as well, but maybe the answer is "don't do that".
"Don't do that" is not very nice advice to people trying to migrate from
CVS to subversion, because they may already have branches that don't
cover the entire project. However, perhaps some cleverness (and more
complex configuration capabilities) in cvs2svn would be good enough.
> I'd like to hear how other folks feel about this proposal. Is it
> general enough? Does it restrict people from doing valuable things?
It's not as general as Greg's rewrite rules. Two features that rewrite
rules could offer that are missing from the projectroot+treeroot
proposal are:
The ability to have branches that cover only a subset of the project;
The ability to map from short nicknames to longer branch names (e.g.
a rewrite rule could map from "B#foo" to "branches/gcc-foo-branch",
while the projectroot+treeroot proposal would require the user to
specify '+branches/gcc-foo-branch").
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/12/05, Marc Sherman <ms...@projectile.ca> wrote:
> It took me a while to figure out what you were doing here with the two
> different properties, but I finally got it.
I'm not quite as reluctant as I should be to set aside clarity for
precision. Sorry about that.
This proposal is the simplest I've seen so far that addresses the
problem for most traditionally-structured repositories. If you've got
your parallel trees scattered around more, it won't work as well, but
maybe the answer is "don't do that".
The error-checking is a definitely a good suggestion. However, we
should make sure the error checking only happens when someone actually
uses the '+' syntax; we don't want to constrain how people use the
repository if they're not interested in our abbreviation. I think
that simply means doing the checks when we expand it.
I'd like to hear how other folks feel about this proposal. Is it
general enough? Does it restrict people from doing valuable things?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
kfogel@collab.net wrote:
>
> 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 :-).
You're right, of course. I definitely should not have included the
caching as part of the core proposal. As Jim mentions, since this
feature would only ever be useful when online, the caching may not even
be necessary at all.
The reason I did mention it, rather than just append "Inherited
properties would make this faster", was that this feature would require
something that I've never seen in an inherited properties proposal
before; we need to know where the property is inherited from, not just
its value.
In fact, in my original proposal, we didn't even care about the value,
just where it was set. I do, however, like Jim's suggestion to put a
sub-path in the treeroot value to handle partial-tree branches.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by kf...@collab.net.
Marc Sherman <ms...@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
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
Jim Blandy wrote:
>
> No, that's not right. You can set the svn:parallel:KIND property on a
> single common parent, and operations in WC's based on any child of
> that parent will see all the branches set there. I show this in the
> example.
It took me a while to figure out what you were doing here with the two
different properties, but I finally got it. And it just gave me another
idea; by combining our two ideas (your two properties, and my regex
matching), we can simplify things even more:
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.
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
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/11/05, Marc Sherman <ms...@projectile.ca> wrote:
>
> Jim Blandy wrote:
> > Here's a revision of my original suggestion that handles deep branch
> > directories nicely. Skip down to 'we will expand arguments'; not much
> > above that has changed.
>
> That still doesn't address my major concern, which is that each branch
> needs to know about all the others. If at some future date, you
> introduce a new branch (or, more significantly, a new class of
> branches/tags, stored in a new namespace), you have to go back and touch
> all your other branches/tags that you might want to compare against it.
No, that's not right. You can set the svn:parallel:KIND property on a single
common parent, and operations in WC's based on any child of that parent will
see all the branches set there. I show this in the example.
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
Jim Blandy wrote:
> Here's a revision of my original suggestion that handles deep branch
> directories nicely. Skip down to 'we will expand arguments'; not much
> above that has changed.
That still doesn't address my major concern, which is that each branch
needs to know about all the others. If at some future date, you
introduce a new branch (or, more significantly, a new class of
branches/tags, stored in a new namespace), you have to go back and touch
all your other branches/tags that you might want to compare against it.
My proposal has a single property set on the common parent dir, so when
a new branching structure is introduced, you only have to touch the dir
prop in one place. Can you think of any layout that your proposal
handles which mine doesn't?
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
Here's a revision of my original suggestion that handles deep branch
directories nicely. Skip down to 'we will expand arguments'; not much above
that has changed.
#!/usr/bin/python
# This is a wrapper for 'svn', the Subversion command-line client,
# that implements a shorthand for referring to files in repository
# trees parallel to the tree in a working copy.
#
# Two directories are "parallel" if it makes sense to compare
# corresponding files in them. A trunk and a branch or tag taken from
# that trunk are parallel, as are two branches from the same trunk.
#
# Parallel directories often have a common ancestor in the repository;
# when this is so, comparison can recognize renamings and copies. But
# directories with no common ancestor can sometimes be parallel, too;
# for example, if you repeatedly import external releases of some
# tree, successive releases can often be usefully treated as parallel
# even though they have no common ancestor in the repository. In this
# case, saying that A and B are parallel simply means that for most
# any relative path R, it makes sense to compare A/R and B/R.
#
# The Subversion book recommends organizing a repository by having a
# 'trunk' directory for the main line of development, and sibling
# 'branches' and 'tags' directories whose contents are trees parallel
# to 'trunk'. This makes it easy to do things in your Subversion
# repository that resemble CVS's 'tag' and 'branch' operations.
#
# However, this organization is clumsy to work with. Given a working
# copy based on a branch, say, you will often want to compare its
# contents with the corresponding files or directories on the trunk;
# similarly for trunk-to-branch comparisons. Without some further
# structure, you must type out the full URL of the parallel directory
# in the repository:
#
# $ svn info
# ...
# URL: http://svn.red-bean.com/repos/project/branch/crazy-idea/doc
# ...
# $ cd doc
# $ svn diff --old . --new http://svn.red-bean.com/repos/project/trunk\
# /doc
#
# (I can't even fit the command on one line in this documentation, and
# I'm not using unrealistic filenames or hostnames.)
#
# There is a lot of redundancy in this command. In the common case:
#
# - We make intra-repository comparisons. You shouldn't need to
# re-type the host name and repository path (here,
# 'http://svn.red-bean.com/repos').
#
# - We make intra-project comparisons. You shouldn't need to re-type
# the project name (here, 'project').
#
# - We compare parallel directories within parallel trees. You
# shouldn't need to re-type the subdirectory (here, 'doc'), since
# it's apparent from your working directory.
#
# Omitting these pieces from the diff command above, we get:
#
# $ svn diff --old . --new trunk
#
# But we still need some indication that 'trunk' is not a local
# relative filename; the presence of the leading URL scheme 'http:'
# used to do this, but that's gone now. For the sake of argument,
# we'll put a '+' in its place:
#
# $ svn diff --old . --new +trunk
#
# (You could argue that --old and --new are redundant, too, but those
# resolve ambiguities in the meaning of the 'svn diff' command
# unrelated to the repository structure. We'll leave those in place
# for now.)
#
# To compare a trunk-based working copy with a particular branch, one
# should be able to type something like:
#
# $ svn diff --old . --new +branch/crazy-idea
#
# There are few more rights we expect:
#
# - You shouldn't need to explain to Subversion the relative positions
# of your 'trunk', 'tags', and 'branches' directories. These were
# established when you first arranged your repository, and are
# essentially static.
#
# - You shouldn't have to distribute some sort of abbreviation list to
# your users to make all this work. You should be able to put the
# needed information in the repository, and always have the current
# data available automatically. (That is, config file tweaking is
# out.)
#
# This wrapper implements the above syntax, based on guidance from
# properties set on directories in the repository. If you use 'svnp'
# instead of 'svn', we will expand arguments of the form
# '+KIND[/SUBDIR]' (where KIND contains no slashes) according the
# following rules, and pass the resulting argument list on to 'svn':
#
# - First, assume that our current working directory is based on the
# repository path BASE.
#
# - Find the lowest parent of BASE that has a property named
# 'svnp:parallel-root'. (The value of this property must be '.';
# don't worry about that for now.) This marks the root of a tree
# which has parallel trees elsewhere. Call this directory PROOT.
# Since it's a parent of BASE, there's some RELBASE such that
# PROOT/RELBASE is BASE. PROOT may be BASE itself, in which case
# RELBASE is '.'.
#
# - Find the lowest parent of RELBASE that has a property named
# 'svnp:parallel:KIND'. Its value should be an absolute repository
# path; call that KINDROOT.
#
# - Replace the '+KIND[/SUBDIR]' argument with the string
# 'KINDROOT/SUBDIR/RELBASE'. (Use '.' for SUBDIR if it's absent, or
# just omit that path element altogether.)
#
# So, the root of every parallel tree needs to be marked with
# 'svnp:parallel-root', and at some parent directory common to all
# your parallel trees you need a bunch of 'svnp:parallel:KIND'
# properties.
#
# Note that, if you place the 'svnp:parallel-root' property at the top
# of your trunk directory, any branch or tag you create by copying the
# trunk off to someplace in a 'branches' or 'tags' directory will
# automatically have its 'svnp:parallel-root' properties set properly.
#
# In our example, the following directories would need the following
# properties:
#
# /project:
# svnp:parallel:trunk = /project/trunk
# svnp:parallel:branch = /project/branches
# /project/branch/crazy-idea:
# svnp:parallel-root = .
# /project/trunk/crazy-idea:
# svnp:parallel-root = .
#
# So, to expand '+trunk' in a working copy based on
# /project/branch/crazy-idea/doc:
#
# - We take BASE to be '/project/branch/crazy-idea/doc', KIND to be
# 'trunk', and SUBDIR (since it's missing) to be '.'.
#
# - We walk up and find the 'svn:parallel-root' property on
# '/project/branch/crazy-idea'; that's our PROOT, and our RELBASE is
# 'doc'.
#
# - We walk up further and find the 'svn:parallel:trunk' property on
# '/project'; its value is '/project/trunk', so that's our KINDROOT.
#
# - The path we substitute for '+trunk' is 'KINDROOT/SUBDIR/RELBASE',
# or '/project/trunk/./doc'. This is the directory corresponding to
# '/project/branch/crazy-idea/doc' on the trunk.
#
# One thing to notice here is that this makes no assumptions about the
# arrangement of the tree above the marked parallel roots, other than
# that one can find an svnp:parallel:KIND property somewhere up there.
# You could have a branch named /project/branches/releases/1.3 ---
# where the branch name itself contains slashes --- and everything
# works fine.
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
Marc Sherman wrote:
>
> 3) construct a regex from the two values:
> (?<=^svn://repos/project1/)trunk|(tags|branches)/[^/]+(?=/)
There's a bug in this step. An extra set of brackes is needed to get
the grouping right; the regex needs to be:
(?<=^svn://repos/project1/)(trunk|(tags|branches)/[^/]+)(?=/)
ie, it will be constructed using:
"(?<=^" + roots-set-on-dir + ")(" + roots-value + ")(?=/)"
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
Jim Blandy wrote:
>
> I think this has two problems:
>
> - If I have a wc based on a branch, how does this help me find the
> corresponding trunk? The repository could have many projects in it. The
> trunk might not be a sibling of the branches directory.
The idea is that everything listed within a single "roots" property is
parallel, to use the terminology from elsewhere in this thread. So if I
had the following multi-project layout:
/
/project1
/trunk
/branches
/tags
/project2
/trunk
/branches
/tags
The project1 and project2 dirs would both have svn:roots properties set to:
svn:roots=trunk|(tags|branches)/[^/]+
The .svn directory in the wc would need to store two additional pieces
of info (I'm guessing in the entries file): The ancestor path that
contains an svn:roots property, and the value of that property.
So, if I'm in a working copy checked out from /project1/branches/r1.x,
and within that working copy I am in the dir src/foo/bar, the command:
svn diff -r +trunk baz.txt
would do the following:
1) check the entries file to find:
roots-set-on-dir = svn://repos/project1
roots-value = trunk|(tags|branches)/[^/]+
2) Assert that the path specified with "-r +" (ie: "trunk") matches the
roots value regex
3) construct a regex from the two values:
(?<=^svn://repos/project1/)trunk|(tags|branches)/[^/]+(?=/)
4) Match the regex against the current dirs repository url
(svn://repos/project1/branches/r1.x/src/foo/bar), replacing the match
with the value given with "-r +". This produces the url:
svn://repos/project1/trunk/src/foo/bar
5) construct the target url to compare by appending the relative
paramater "baz.txt", giving:
svn://repos/project1/trunk/src/foo/bar/baz.txt
> - The regexp given assumes that there is only one directory component after
> 'branches'; that is, every subdirectory of 'branches' must be a root. But we
> encourage people to take advantage of the fact that the branch 'namespace'
> is really just part of the directory tree, and use hierarchy within branch
> names: 'experimental/wacko'. If all your branch names were two levels deep,
> then you could fix the regexp. Or if all your root names ended in '%' (say),
> and never used % elsewhere, then you could fix the regexp.
Consider a third project in the same repository as above:
/project3
/trunk
/dev
/experimental
/exp1
/releases
/r1.0
/r1.x
/r1.1
On the project3 dir, I'd set:
svn:roots=trunk|dev|experimental/[^/]+|releases/(r1.x/[^/]+|(?!r1.x)[^/]+)
You'd need to use libpcre for this level of regexp complexity, I think.
It appears to be portable already to all of Subversion's supported
platforms, I think.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/10/05, Marc Sherman <ms...@projectile.ca> wrote:
>
> Here's a simpler idea, that requires only a single property, set on the
> parent directory of trunk/branches:
>
> svn:roots = (trunk|branches/[^/]+)
I think this has two problems:
- If I have a wc based on a branch, how does this help me find the
corresponding trunk? The repository could have many projects in it. The
trunk might not be a sibling of the branches directory.
- The regexp given assumes that there is only one directory component after
'branches'; that is, every subdirectory of 'branches' must be a root. But we
encourage people to take advantage of the fact that the branch 'namespace'
is really just part of the directory tree, and use hierarchy within branch
names: 'experimental/wacko'. If all your branch names were two levels deep,
then you could fix the regexp. Or if all your root names ended in '%' (say),
and never used % elsewhere, then you could fix the regexp.
Re: Easy comparisons between related trunks, branches, and tags
Posted by Marc Sherman <ms...@projectile.ca>.
Alan Barrett wrote:
>
> What I meant was, if I have the following structure:
>
> trunk/ [svn:parallel:foo = ../branches/foobranch]
> [svn:parallel:bar = ../branches/barbranch]
> branches/
> foobranch/ [svn:parallel:trunk = ../../trunk]
> barbranch/ [svn:parallel:trunk = ../../trunk]
>
> and I have a working copy somewhere in foobranch,
> and I try to refer to "+bar", it doesn't work.
>
> Hmm, what if there was a mechanism for indirection through
> the properties on a different directory?
>
> trunk/ [svn:parallel:foo = ../branches/foobranch]
> [svn:parallel:bar = ../branches/barbranch]
> [svn:parallel:trunk = .]
> branches/
> foobranch/ [svn:parallel:* = ../../trunk]
> barbranch/ [svn:parallel:* = ../../trunk]
>
> Now if I have 100 branches, then I need to set 100 dirprops on the
> "trunk", but the other 99 branches just need the indirection specifier
> to tell them "look at the trunk's dirprops for information about other
> branches".
Here's a simpler idea, that requires only a single property, set on the
parent directory of trunk/branches:
svn:roots = (trunk|branches/[^/]+)
Cons:
- Need to set the property on the parent dir. Does subversion support
dirprops on the root of the repository?
- Need a regex library in subversion, which I understand is a new
requirement. I don't think it's an onerous one, personally.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Martin Furter <mf...@rola.ch>.
On Thu, 10 Nov 2005, Alan Barrett wrote:
> On Wed, 09 Nov 2005, Jim Blandy wrote:
>>> If several branches are each declared
>>> as parallel to the trunk, how do we know that the branches are also
>>> parallel to each other?
>>
>> You could set an svn:parallel:branch property on some parent of the
>> branches, as well as on (a parent of?) the trunk; then +branch would work
>> everywhere.
>
> What I meant was, if I have the following structure:
>
> trunk/ [svn:parallel:foo = ../branches/foobranch]
> [svn:parallel:bar = ../branches/barbranch]
> branches/
> foobranch/ [svn:parallel:trunk = ../../trunk]
> barbranch/ [svn:parallel:trunk = ../../trunk]
>
> and I have a working copy somewhere in foobranch,
> and I try to refer to "+bar", it doesn't work.
>
> Hmm, what if there was a mechanism for indirection through
> the properties on a different directory?
>
> trunk/ [svn:parallel:foo = ../branches/foobranch]
> [svn:parallel:bar = ../branches/barbranch]
> [svn:parallel:trunk = .]
> branches/
> foobranch/ [svn:parallel:* = ../../trunk]
> barbranch/ [svn:parallel:* = ../../trunk]
>
> Now if I have 100 branches, then I need to set 100 dirprops on the
> "trunk", but the other 99 branches just need the indirection specifier
> to tell them "look at the trunk's dirprops for information about other
> branches".
>
>>> And how do we know how many directory
>>> components are part of the branch specifier, as opposed to part of the
>>> directory within the branch?
>>
>> Right, that's another question that I was trying to get at here:
>>
>> # ... But how do you eliminate branch names in
>> # 'branches/branchname/subdirs'? If there's deep hierarchy under
>> # 'branches', you don't know how many components to drop to find the
>> # trunk, but keep subdirs.
>
> Perhaps make the property value look like a structured data type with
> multiple subvalues, one of which says how many directory levels to chop
> off?
>
> trunk/ [svn:parallel:branches = (dir="../branches/*",chop=1)]
> branches/ [svn:parallel:trunk = (dir="../trunk",chop=2)]
> [svn:parallel:branches = (dir="./*",chop=2)]
> foobranch/
> barbranch/
>
> Now "+trunk", "+branches/foobranch" and "+branches/barbranch" should
> work from anywhere.
But there's a problem when creating a new branch:
svn cp $REPOSURL/trunk $REPOSURL/branches/bazbranch
Now I have:
trunk/ [svn:parallel:branches = (dir="../branches/*",chop=1)]
branches/ [svn:parallel:trunk = (dir="../trunk",chop=2)]
[svn:parallel:branches = (dir="./*",chop=2)]
foobranch/
barbranch/
bazbranch/ [svn:parallel:branches = (dir="../branches/*",chop=1)]
My new branch has no info about where trunk is and wrong info about the
branches.
Why not specify absolute path and set only one property containing
multiple lines like that:
svn propset svn:parallel "trunk project1/trunk
branches project1/branches/*
tags project1/tags/*" .
Then branching and tagging will neither lose properties nor inherit
properties with wrong values.
-Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Alan Barrett <ap...@cequrux.com>.
On Wed, 09 Nov 2005, Jim Blandy wrote:
> > If several branches are each declared
> > as parallel to the trunk, how do we know that the branches are also
> > parallel to each other?
>
> You could set an svn:parallel:branch property on some parent of the
> branches, as well as on (a parent of?) the trunk; then +branch would work
> everywhere.
What I meant was, if I have the following structure:
trunk/ [svn:parallel:foo = ../branches/foobranch]
[svn:parallel:bar = ../branches/barbranch]
branches/
foobranch/ [svn:parallel:trunk = ../../trunk]
barbranch/ [svn:parallel:trunk = ../../trunk]
and I have a working copy somewhere in foobranch,
and I try to refer to "+bar", it doesn't work.
Hmm, what if there was a mechanism for indirection through
the properties on a different directory?
trunk/ [svn:parallel:foo = ../branches/foobranch]
[svn:parallel:bar = ../branches/barbranch]
[svn:parallel:trunk = .]
branches/
foobranch/ [svn:parallel:* = ../../trunk]
barbranch/ [svn:parallel:* = ../../trunk]
Now if I have 100 branches, then I need to set 100 dirprops on the
"trunk", but the other 99 branches just need the indirection specifier
to tell them "look at the trunk's dirprops for information about other
branches".
> > And how do we know how many directory
> > components are part of the branch specifier, as opposed to part of the
> > directory within the branch?
>
> Right, that's another question that I was trying to get at here:
>
> # ... But how do you eliminate branch names in
> # 'branches/branchname/subdirs'? If there's deep hierarchy under
> # 'branches', you don't know how many components to drop to find the
> # trunk, but keep subdirs.
Perhaps make the property value look like a structured data type with
multiple subvalues, one of which says how many directory levels to chop
off?
trunk/ [svn:parallel:branches = (dir="../branches/*",chop=1)]
branches/ [svn:parallel:trunk = (dir="../trunk",chop=2)]
[svn:parallel:branches = (dir="./*",chop=2)]
foobranch/
barbranch/
Now "+trunk", "+branches/foobranch" and "+branches/barbranch" should
work from anywhere.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/9/05, Alan Barrett <ap...@cequrux.com> wrote:
>
> I think that Greg's idea of transformation rules required the two
> directories to have a common ancestor (at which there would be a dirprop
> describing the transformation rule), whereas your idea doesn't need
> a common ancestor (placing the necessary dirprops at the "trunk" or
> "branches/foobranch" or "vendor/release" level, not at the "project"
> level).
Yes --- at the cost of having to place more properties.
I noticed two unsolved problems: If several branches are each declared
> as parallel to the trunk, how do we know that the branches are also
> parallel to each other?
You could set an svn:parallel:branch property on some parent of the
branches, as well as on (a parent of?) the trunk; then +branch would work
everywhere.
And how do we know how many directory
> components are part of the branch specifier, as opposed to part of the
> directory within the branch?
Right, that's another question that I was trying to get at here:
# ... But how do you eliminate branch names in
# 'branches/branchname/subdirs'? If there's deep hierarchy under
# 'branches', you don't know how many components to drop to find the
# trunk, but keep subdirs.
Re: Easy comparisons between related trunks, branches, and tags
Posted by Alan Barrett <ap...@cequrux.com>.
On Tue, 08 Nov 2005, Jim Blandy wrote:
> # Two directories are "parallel" if it makes sense to compare
> # corresponding files in them. A trunk and a branch or tag taken from
> # that trunk are parallel, as are two branches from the same trunk.
Yes, this definition of "parallel" is exactly the right way of looking
at the problem.
I think that Greg's idea of transformation rules required the two
directories to have a common ancestor (at which there would be a dirprop
describing the transformation rule), whereas your idea doesn't need
a common ancestor (placing the necessary dirprops at the "trunk" or
"branches/foobranch" or "vendor/release" level, not at the "project"
level).
I noticed two unsolved problems: If several branches are each declared
as parallel to the trunk, how do we know that the branches are also
parallel to each other? And how do we know how many directory
components are part of the branch specifier, as opposed to part of the
directory within the branch?
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Easy comparisons between related trunks, branches, and tags
Posted by Greg Hudson <gh...@MIT.EDU>.
[I'll duplicate my response in a vain hope for thread sanity.]
On Tue, 2005-11-08 at 22:57 -0800, Jim Blandy wrote:
> I'm trying to outgrow my control-freak habits, so I'm forcing myself
> to expose my tender sketch to y'all's stone-hearted criticism.
Basically, I think we want two things different from your proposal:
* On the property front, I think we want to be a little less generic.
Teach the client about trunk, branches, and tags. This generic "kind"
stuff will be too hard for users to wrap their heads around, and will
require extra typing every time you use the command.
* On the syntax front, I'm not sure that thinking about this in terms
of URL transformation will yield good results. "svn diff
--old=branch1-shorturl/file --new=branch2-shorturl/file" doesn't seem as
natural as the more CVS-like "svn diff -r
branch1-specifier:branch2-specifier file".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org