Ryan Schmidt wrote:
> On Oct 15, 2005, at 18:08, John Waycott wrote:
>
>> I've been thinking about how to solve a problem with getting large
>> binary files that projects use in their builds. This includes
>> library modules, PDF files created in Marketing, tools, etc. I know
>> that SVK could solve some of our problems but for various reasons is
>> currently not an option for us.
>>
> As you've discovered, SVK is a way to maintain multiple copies of a
> repository. If you don't tell us why you don't want to use it, we
> can't help you work around them. There are also other ways to mirror
> a repository; I think I heard about something called SVN-Mirror. You
> could look into that.
>
Thanks - I'll look at SVN Mirror. The reasons we can't use SVK are:
1. We use TortoiseSVN and SVK doesn't work seamlessly with it. We're
afraid developers will commit incorrectly, fail to push the mirror to
the central repo, etc. The potential of making mistakes seems greater
with SVK.
2. SVK doesn't have the exposure that Subversion has. We want to wait
until we are confident it is robust and we can get the support we need
should that be required.
3. No svn:externals support. We are using that in some projects currently.
>> Also, these files should be read-only; the developer would not be
>> able to modify them since they don't have the tools nor expertise
>> for working on those projects.
>>
> Subversion has features that let you manage read/write permissions
> for specific users for specific directories. Look in the book for
> "authz."
>
We use svn: protocol now, so we have to wait until 1.3 to get that
feature, but even so, the context here is such that the developer
shouldn't change the file. This can be handled with procedures, but I'd
rather not give the developer the option.
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 17 16:52:19 2005