Brian Denny <brian@briandenny.net> writes:
> so let me get this straight: the benefit of the --in-repos-template
> feature is that it allows you to say
>
> svnadmin create --in-repos-template=TEMPLATE /path/to/repos
>
> instead of
>
> svnadmin create /path/to/repos
> svnadmin import file:///path/to/repos /path/to/TEMPLATE
I think that's an accurate summary, yes.
Regarding your question about project layouts, the first layout you
listed is not the recommended one. Both the second and third layouts
are recommended, however, because they're both special cases of the
general pattern
.../.../.../PROJECT_ROOT/trunk
/branches
/tags
The project root might be "/", it might be "/clients/myclient/", it
might be "/myproject/", or anywhere else. But once you're *at* a
project root, we recommend laying out the standard three subdirs
beneath it.
The book doesn't document this yet, iirc, that's why the confusion.
-Karl
> there seems to be some confusion over what our 'recommended layout
> convention' really is. (at least, *i'm* confused. :-)
>
> if it is
>
> /trunk
> /projectA
> /projectB
> /tags
> /projectA
> /projectB
> /branches
> /projectA
> /projectB
>
> then having the option to 'svnadmin create' makes some sense, since
> the convention implies a single use case, which the feature supports.
>
> if it is
>
> / # implicit/main project
> /trunk
> /tags
> /branches
> /path/to/projectB
> /trunk
> /tags
> /branches
>
> (as i *think* Karl stated in his recent e-mail), then the feature
> supports creating the layout under '/', but not under '/.../projectB',
> which i think is wacky, especially since the user could cover both use
> cases by just learning how to do it with 'svn import'.
>
> and if it is
> /projectA
> /trunk
> /tags
> /branches
> /projectB
> /trunk
> /tags
> /branches
>
> (with no implicit project at '/', which is probably the layout that
> i'd prefer), then the feature is pretty much useless (unless i'm
> missing something, which is entirely possible).
>
>
> -brian
>
>
> ---------------------------------------------------------------------
> 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
Received on Wed Apr 16 21:18:41 2003