On Fri, Nov 21, 2008 at 6:49 PM, David Chapman <dcchapman_at_earthlink.net> wrote:
> Blair Zajac wrote:
>>
>> Alain Palamara wrote:
>>>
>>> Hi all,
>>>
>>> I read a lot of messages concerning read only working copy, but didn't
>>> find a clear answer to my problem. I will explain you my situation:
>>>
>>> - We are developping FPGAs and use SVN to keep our source code and
>>> projects.
>>> - We are a team of developpers sharing projects and source code.
>>> - We use the svn:externals to checkout our IPs (common source files)
>>> into the projects.
>>> - Until now everthing is perfect. The fact is the IPs are shared by
>>> many projects and shall be modified/corrected with care. So we decided
>>> that only few people can commit the IPs that must be validated across
>>> projects. As we recommend developpers to explicitly
>>> name the directory that refers to IPs in external repositories, we
>>> would like to have them read only in the working copy to reduce the risk
>>> a developper modifies an IP, generate the FPGA bit stream (equivalent to
>>> the executable) and commits the project.
>>> Because the IPs will not commited at the same time the project and
>>> because the developper probably don't have the right to commit the IP,
>>> we become in this in a situation where the commited project is corrupted
>>> (refers wrong IP source) and can not regenerate the FPGA
>>> after a checkout.
>>>
>>> Ok, I hope my explanation was clear ;)
>>>
>>> So my question is: Is there a way to checkout externals as read only?
>>>
>>> I can imagine a "post-checkout" or "post-update" hook, but it doesn't
>>> exist. Or a better way could be a flag in the svn:externals property
>>> that specify per external if it is read only or not. Something like:
>>> [-r<revision>] [-read-only] <repos-url> <ext_dir>
>>>
>>>
>>> Any plan to support this in the futur?
>>
>> No, there's no plan to support such a feature.
>>
>> The solution now is to ensure that only authorized developers can commit
>> to the URLs that the external refers to, so you'll want some per-directory
>> access control set up.
>>
>> Regards,
>> Blair
>>
> In answer to the questions (although I am not a chip designer, I play one on
> TV ;-) the issue is that if a designer makes a local change to the IP
> directory before running the FPGA design software, the results of that run
> cannot be reproduced by anyone else. Reproducibility is very important in
> chip design. To do this, you need to prevent local changes in addition to
> preventing unauthorized commits of changes.
>
> Think of the FPGA design tool as a very fancy C or C++ compiler which
> generates highly optimized binary code. The binary code is of course what
> gets "shipped" (in this case, downloaded to the FPGA). The compiler is very
> sensitive to the flags used and the input given, so knowing how you got
> those good (or bad) results is very important. You don't want someone
> committing changes that are good only because the IP block was modified
> locally. As you might expect, the binary does not have any information
> stored in it that would help you determine how you got it.
>
> This is not a revision management issue; this is a design process issue.
> Subversion is a lightweight revision management system that does not
> attempt to control the workspace that is checked out. As you've heard, this
> is not likely to change. You will have to provide an external means of
> creating the read-only workspace directories.
>
> I can think of two possible solutions offhand:
>
> 1) Don't give designers direct access to Subversion; write wrapper scripts
> that populate the workspace and change file permissions for the directories
> containing the IP blocks. You'll need one to check out and one to commit.
> 2) Don't give designers direct access to the IP blocks through Subversion;
> export the current versions into global read-only directories. IP blocks
> should not be changing very often for designers using them anyway.
>
> Option 1) is necessary if your design tools require write access to the IP
> directories in order to store output data such as netlists created for
> sub-blocks. In this case nothing in a Subversion-based design flow will
> prevent designers from changing file permissions manually and editing files
> locally. You'll need something much more controlling, like DesignSync or
> ClearCase, to prevent this entirely.
>
> --
> David Chapman dcchapman_at_earthlink.net
> Chapman Consulting -- San Jose, CA
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
Is there a reason a pre-commit hook can't be used to block commits to
the directories containing the externals, this would not prevent
working copy modifications but would block any commits upstream that
might pollute the IP. I don't think a pre-commit hook could be made
conditional on a working copy (shell back to the committer & check svn
status??) but you might be able to wrap the svn command with your own
command that does the svn status check on the externals when a svn ci
is called - TortoiseSVN may have this already as a feature - client
side is never easy with Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-22 09:50:05 CET