On 2/3/07, Ryan Schmidt <subversion-2007a@ryandesign.com> wrote:
> On Feb 2, 2007, at 18:34, Kylo Ginsberg wrote:
> > 1) cvs versions the administrative files b/c CVSROOT is a special
> > directory, whereas subversion does not. It would be nice if admin
> > files (e.g. hooks and files they use) were under revision control. Is
> > there a recommended practice in this regard?
>
> You can check your hooks and configs into the repository if you want.
> You can write a post-commit hook that would auto-update the configs
> and hooks. This way, anyone could check out the hooks or configs on
> their desktop, change something, commit it, and the server would auto-
> update. If this is what you want, then it can be done.
Thanks, this is a fine idea: basically define a special directory in
the repository a la CVSROOT, and have the post-commit hook for said
directory update the hooks directory. Might get a little exciting if
the post-commit hook itself is what's being committed, but that can be
special-cased.
I wonder if the svn dev team has considered incorporating this
functionality into the tool itself as cvs does?
> > 2) We have a long history of using cvs modules, so that various
> > projects can select the directories of interest on checkout. Right
> > now, we plan to write a script to parse the existing modules file and
> > do checkouts based on those modules. I looked in collab.net's contrib
> > for such a script. Has anyone written something like this and/or is
> > there a recommended practice?
>
> I believe you want svn:externals here. See the book:
>
> http://svnbook.red-bean.com/en/1.2/svn.advanced.externals.html
I've considered using externals for this purpose but backed away for
the following reason. Let me know if I'm missing something but if you
check out using externals (even if from the same repository), you
cannot atomically commit across those externals. So I need to give up
commit atomicity with this approach, something I'm reluctant to do.
Hence the idea of a modules-ish script. Thoughts?
Thanks,
Kylo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 3 21:55:50 2007