Re: An enhancement for SVN about properties and checkout

On Mon, Jun 26, 2006 at 10:53:53PM +0200, Christophe Blanchard wrote:
> Here is an enhancement that could be useful for our development team :
> "Using properties to filter checkouted files".
>
> I think that it can be interesting to checkout partially a repository,
> only files with a specific property or files with specific property set
> to a specific value.
>
> In our case, we are working on a lot of files those are not compiled
> together. So it's not useful for us to have all the repository files at
> the same time.

I do something similar. I am using svn for tracking system
configuration files think svn for cfengine. Since there are multiple
independent subsystems in the tree, and multiple people working in the
tree, the files I push to production systems is almost never the head
revision of the working tree.

> I haven't see anything on this subject in the issue tracker. Is there
> anybody interested in this enhancement ?

I have a few issues that would be eased using this mechanism:

   1) tagging files ready for production without a checkout/merge
      cycle onto a production branch.

   2) tracking which files in the trunk are derived by merging from
      files in a particular vendor branch.

The prior system I worked with was cvs and there I could tag a file
revision which provided a collection/point in time method of grouping
files. I don't see an equivalent under svn. To group files together
you must make a group in space (svn tag or branch) which is
conceptually (to me) not quite the same. I don't want to merge files,
I want to set a known point in the revision tree of the "one true
copy" of the file and then repeat this for 1000 files. That way I can
do away with my production branch entirely since changes to it are
exclusively the result of merges from the trunk.

So being able to do the equivalent of:

   svn up -r prop:production:LATEST

to get my working copy files updated to the latest revision of the
file that has the "production" property would be great. It should also
delete files that no longer have the production property.

   svn co -r prop:production:LATEST svn+ssh://host/svn/Config/work

would be similar to check out a tree matching the criteria above.
If the file was missing the property, it just wasn't checked out.

The question is what to do with directories? Maybe choose the
directory at the same revision as the maximum version of the checked
out files under it?

Also under cvs I used to keep vendor trees with pristine copies of all
the configuration files I change. This way I can easily identify
changes in configuration file format and contents between say fedora
core 3 and fedora core 4 and merge them into the config files I push
out to all my fedora boxes. These tree's are built up over time, as I
make changes on the systems, I put the original config files into the
vendor tree. Then I copy that into the working tree and do merges etc
from then on.

I am currently experimenting with the best way to do this under
subversion. However I need to track (for example):

  files in fedora 3
  vendor upgrades to files in in fedora 3
  files in fedora core 4
  vendor upgrades/patches in fedora core 4 etc. Repeat for 5 os's.

So I set up tag_fc3, tag_fc3_ssh_upgrade1, tag_fc4 etc. I would prefer
to have just an fc3 tree and an fc4 tree, but I can't. I need to be
able to find all the original fc3 files and the only way to do that is
to keep a totally separate tree because I have this update mode:

  1 check in fc3 files - at this time the tree is just the base fc3
  2 check in new ssh config file provided by vendor on update
  3 check in new core fc3 file for apache that I just started
       maintaining.

Now I have no single revision that will pull out just the original fc3
files. So I basically have to maintain an extra tree for every single
update to a file and use copy to make branch points.

However is I was able to select files by property, I could add a
"vendor_release=fc3base" to the files in steps 1 and 3 and be able to
extract them. At step 2 I could add "vendor_release=fc3:ssh-3.6.1-2" etc.

Also having multiple tree's makes merging more of a pain as I have to
select a revision and different trees to get the merge to occur rather
then just:

  svn merge -r 20:30 \
     svn+ssh://.../vendor/fc3/etc/ssh/sshd_config ssh/sshd_config.fpp

or better:

     svn merge -r vendor_release=fc3base:vendor_release=ssh-3.6.1-2 \
       /vendor/fc3/ets/ssh/sshd_config ssh/sshd_config.fpp

I also use properties to track mergepoints but in a different
application. I talked a bit about in in an email a few hours ago with
my response to "Complex tag creation performance". If I could do an:

  svn list -r mergepoint=.*fc3:ssh-3.6.1-2

or

  svn list -r mergepoint=.*centos4.1.*

to get lists of files that had the mergepoint tag include centos4.1 or
a particular revision of a config file it would make things much
easier to track. It is probably of more use for large merges (such as
when deploying a new version of the OS) that can touch dozens of files
that have to be verified for the new OS release.

I am not sure what sorts of changes would have to go on at the svn
level to implement your idea. My guess is that it wouldn't be trivial
but I think it is definitely worth it as it also can provide a
mechanism for SVN to track merge points automatically.

-- 
				-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org