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.
>
> Some background...
>
> We have several departments and offshore offices contributing to
> projects. They release their sub-components separately. This is
> necessary because the components may be used in more than one
> parent project; A library may be used in dozens of final product
> lines.
>
> For example, the Marketing department uses FrameMaker to create an
> installation guide. When they are done, the final output is a PDF
> file. This file is then used as source to the final build which
> uses scripts for creating ISO images from all of the pieces. The
> scripts are stored in Subversion.
>
> There are two usual approaches for saving the output files: 1.
> Store the files in a separate file share releases area, 2: Store
> them in a release area in Subversion.
>
> The first solution requires a script to get the files, the second
> would use something like svn:externals to get the files.
>
> Here is the problem we have using svn:externals:
> In some cases, the external files can approach 100MB in size. It is
> impractical to use svn:externals for our purpose, because the
> checkouts over a slow link could take literally hours.
>
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.
Note that you only have to transfer the full file on the very first
checkout. Subsequent updates of the working copy will only transmit
the differences between the version you have and the current one, and
so should be much faster and hopefully more acceptable over a slow
link. Subversion is designed with slow networks in mind.
> 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."
> Storing the output files in a shared releases area solves the speed
> problem for us because we can mirror the shared releases area in
> the various development centers.
>
> My proposal:
>
> What I'd like is for svn checkout to run the script to grab the
> needed release files.
>
> A folder property 'svn:run' folder would reference a script in the
> current folder. svn checkout would execute the script referenced in
> svn:run. You could get around platform dependence by specifying
> different scripts for different platforms. So for example, the
> svn:run property may have as its value:
>
> win32:getfiles.bat linux:getfiles
>
> I'm sure there are all kinds of issues with doing something like
> this that I haven't thought of, but I'd be interested if others
> have had similar issues.
>
Sounds like you're talking about client-side scripts, which is a
topic which has come up on the list many times before. I'm sure there
are open feature requests for this too. You could search the issue
tracker and mailing list to see what kind of problems with this idea
people have discussed before.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Oct 16 17:17:49 2005