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
Received on 2008-11-22 02:50:28 CET