Johan Corveleyn wrote on Thu, Jan 20, 2011 at 13:40:49 +0100:
> If someone decides to put a lot of effort in this for a custom
> solution, you may want to consider another option: to take a good look
> at issue http://subversion.tigris.org/issues/show_bug.cgi?id=2662
> (authz with wildcards), and t
On Thu, Jan 20, 2011 at 10:41 AM, Jan Keirse wrote:
> David Aldrich schreef op 20/01/2011 10:24:28:
>
>> Hi Jan
>>
>> > I've changed my mind, there is something that may be better than
>> > externals, although it requires a little trick.
>> > You should be able to create a commit hook that check
David Aldrich schreef op 20/01/2011 10:24:28:
> Hi Jan
>
> > I've changed my mind, there is something that may be better than
> > externals, although it requires a little trick.
> > You should be able to create a commit hook that checks if the authz
file
> > reflects the restrictions you want
Hi Jan
> I've changed my mind, there is something that may be better than
> externals, although it requires a little trick.
> You should be able to create a commit hook that checks if the authz file
> reflects the restrictions you want on a specific folder
> (*/thesecretfolder/*) for the branch
>
Jan Keirse schreef op 19/01/2011 10:58:24:
> David Aldrich schreef op 19/01/2011 10:42:15:
>
> > Hi
> >
> > I'd like to explain my high level problem, which I hoped externals
> > would solve. Maybe someone will have a suggestion how to properly
> > address this.
> >
> > Our source code is u
Hi Jan
> In the future hopefully an authz file with wildcards will solve the
> problem:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2662
>
> Right now I don't there's anything better than externals.
Thanks, I think that this is what we need. However, I can't see this on the
svn roadm
David Aldrich schreef op 19/01/2011 10:42:15:
> Hi
>
> I'd like to explain my high level problem, which I hoped externals
> would solve. Maybe someone will have a suggestion how to properly
> address this.
>
> Our source code is used by several developer groups. A few files
> need to be conf
Hi
I'd like to explain my high level problem, which I hoped externals would solve.
Maybe someone will have a suggestion how to properly address this.
Our source code is used by several developer groups. A few files need to be
confidential to one group. We can set access permissions on these fil
Hi again,
never to old to learn something ... ;-)
Am 19.01.2011 10:26, schrieb Martin Rabl:
Am 19.01.2011 10:02, schrieb David Aldrich:
> to do this, so how can we prevent such commits being made?
IMHO there is no way to prevent external commits - it would be contrary
to the principles of svn,
Hi Martin and Jan
> You mean: not to the repository, where the other repository is linked
> into via svn:external?
Sorry, I have misunderstood the manual. I thought that commits to a file in the
folder that has the svn:external property would not be reflected in the source
repo. This is not tru
Hi,
Am 19.01.2011 10:02, schrieb David Aldrich:
1) Subversion allows you to commit a change within the
> directory that uses the svn:external property.
> This change will not be committed to the referenced
> (source) directory/repo.
You mean: not to the repository, where the other repository is
David Aldrich schreef op 19/01/2011 10:02:43:
> Hi
>
> I wonder if anyone would answer the following questions about svn:
> external for me please?
>
> 1) Subversion allows you to commit a change within the directory
> that uses the svn:external property. This change will not be
> committed t
Hi
I wonder if anyone would answer the following questions about svn:external for
me please?
1) Subversion allows you to commit a change within the directory that uses the
svn:external property. This change will not be committed to the referenced
(source) directory/repo. I can't imagine a circ
13 matches
Mail list logo
