[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Using svn:externals

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-09-10 22:40:29 CEST

On Sep 10, 2007, at 12:49, Hari Kodungallur wrote:

> On 9/10/07, Rob Wilkerson wrote:
>> I've spent a lot of time looking and there's a lot of material out
>> there, but either it doesn't cover my situation or I'm not informed
>> enough to recognize the correlation. That's my attempt at an apology
>> if my question has an obvious answer. :-)
>> I have a set of code that needs to be shared across existing projects
>> and also with future projects whose project directories haven't yet
>> been created (I have one repository with many top level project
>> directories). Essentially, every new project directory needs to
>> include these same external directories. Is there any way to
>> automate
>> this? Once the project is identified, I create the project directory
>> by importing a directory "template" that includes the /branches, /
>> tags
>> and /trunk directory.
>> Is it possible to somehow attach the external directories to the
>> trunk
>> without another step to my process?
> I do not know of any method that automates the setting of
> svn:externals for newly created projects. It would have been nice
> if we could use auto-props to set svn-externals [May be we can do
> it, but I have never tried it.. I always thought you need an
> SVN_EDITOR to set the externals].

You don't need to use an editor to set externals or any other
property; you can "svn propset" at the command line.

However, auto-props cannot be used to automatically set
svn:externals, because svn:externals needs to be set on a directory
(not a file), and auto-props only works with files (not directories);


(Though a patch is provided there to implement this feature.)

> Rather than "import"ing the directory template, is it possible to
> keep the template in the repository itself?
> Something like:
> svn-root
> - template
> - trunk
> - branches
> - tags
> Then set the externals on the trunk. And when you have a new
> project, instead of importing, you can just copy the template
> directory to the new project directory. That way, the externals get
> copied as well.

That was going to be one of my suggestions. Probably the best

Another option would be to create a new repository

$ svnadmin create templaterepo

and set it up exactly as you want your project template to be -- with
trunk, branches and tags directories, and svn:externals and any other
properties set as you want them. Don't create a top-level directory
"template"; just put everything in your default project right at the
root of the repository.

$ svn co file:///path/to/templaterepo templatewc
$ cd templatewc
$ svn mkdir trunk branches tags
$ svn ci -m ""
$ svn propset svn:externals whatever whatever
$ svn ci -m ""

Take as many revisions as you like doing this. Once you're done, dump
the head of the repository to a dumpfile.

$ svnadmin dump -r HEAD templaterepo > templatedump

Now whenever you want to start a new project you can load the
dumpfile into the right place in your main repository.

$ svnadmin load --ignore-uuid --parent-dir /newprojectname /path/to/

The date/timestamp of the revision will not be "now"; will be from
whenever the dumpfile was made (or will be from the head revision of
the templaterepo?) but you can switch it to "now" by editing the
svn:date revision property of the revision you just committed

$ svn propset svn:date --revprop -rWHATEVER file:///path/to/mainrepo

after importing. Same for svn:author if the author of the template is
not the person importing the new project structure now.

This is all from memory so please excuse any typos.

If you do it this way, instead of the way Hari suggested, the history
of each project will start with this imported revision, instead of
being traceable back to the template. This may be good or bad
depending on your point of view.

The one downside I see is that if you ever want to change your
project template, it's a bit less convenient, because you have to go
back to the templaterepo, make the change, and create a new dumpfile.
Also, you have to keep the dumpfile around somewhere, or regenerate
it each time you need it from the templaterepo. Alternately, you
might delete the templaterepo after creating the templatedump. If so,
then, to change your template, you need to create a new repo, load
the templatedump, make changes, create a new templatedump, and delete
the repo again. Getting a bit cumbersome. If you do keep the
templatedump file around, where do you keep it? On a file server? In
your main repository? If the latter, you may as well just keep the
template structure itself in your main repo and "svn copy" it like
Hari said.

My scheme also assumes you have direct filesystem access to the
repository whenever you need to do this. If you don't, that's another
reason to just "svn copy".

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 10 22:38:54 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.