On Jul 28, 2008, at 20:21, David Weintraub wrote:
> I guess I am mistaken. I could have sworn that svn:externals were
> read-only. In fact, I thought it was a great idea because it meant
> that you were forced to check out and create a separate work area in
> order to change the external code. That would make you think twice for
> touching a common function or class that others depend upon.
>
> How does Subversion treat externals for hooks, then?
>
> For example I have:
>
> svn://projects/foo/trunk and I put on this directory an svn:externals
> property of
>
> common svn://common-projs/common
>
> If I changed the file svn://project/foo/trunk/common/bar.java, would
> that file be recognized by the hook as
>
> svn://common-projs/common/bar.java
>
> Or
>
> svn://projects/foo/trunk/common/bar.java?
>
> If it was the latter, it would make permission pre-commit hooks almost
> impossible to enforce.
The file svn://project/foo/trunk/common/bar.java does not exist and
neither does the directory svn://project/foo/trunk/common. Instead,
the directory svn://project/foo/trunk exists, and on it, you have set
the svn:externals property to "common svn://common-projs/common"
which causes a Subversion client to do special things on checkout.
Namely, if you check out the trunk directory, Subversion will
afterwards check out svn://common-projs/common into a new directory
"common" inside that working copy. That "common" working copy is not
connected to the "trunk" working copy in any real way. Changes you
make and commit to the "common" working copy will of course go to the
repository location from which they came, namely svn://common-projs/
common.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-29 07:51:08 CEST