[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 <kfogel@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
Received on Wed Nov 9 08:22:02 2005