Peter
> Our scenario is as follows: we have a repository with a
> number of files and directories at the top level. One of the
> directories contains large binary content files (7GB, which
> doubles to 14GB when duplicated by svn to create clean local
> copies). Many developers would like to omit this directory
> when they do checkouts (to avoid having to buy new disk drives!).
I've had the same problem and used "externals" linking back into the
***same*** repository as a workaround. Not ideal but (for me) it avoids
having to download 1GB over 128K ADSL line.
The repository looks like:
repo/Trunk/Dir1
/Dir2
/Dir3 <- HUGE
/workspace/ <--- empty except for metaproperties
specifying
externals: Dir1 reppPath/trunk/Dir1
externals: Dir2 repoPath/trunk/Dir2
When I check out "/workspace" it downloads Dir1 & Dir2 as intended and
committing "workspace" correctly pushes changes in the Dir1 & Dir2
working copies back into their correct locations in /Trunk.
Been using it for several weeks - works well.
Important - make sure that /workspace is parallel to /Trunk NOT part of
it. Initially, I had /workspace at the same level as /Dir1,2 & 3. This
worked well UNTIL I tried to check out all of /Trunk. With workspace in
/Trunk/workspace, checking out /Trunk ended up with two copies of Dir1 &
Dir2 being checked out, the correct ones at the top level, and
duplicates as /Trunk/workspace/Dir1 (same for Dir2).
I have a complete checked out MasterCopy (all of /Trunk) which is
occassionally updated, just so (for the truly paranoid) not all the data
is in an inaccessible MySQL format.
My /workspace actually moves directories about a bit to "make visible"
(at the top level of /workspace) the particular directories I need at
the moment, so the /workspace tree can be a subset or a reorganised set
of the folders in /Trunk.
Hope this helps
Cheers
Giovanni.
========================================================================
Giovanni Moretti | Institute of Information Sciences and Technology
Senior Lecturer | Massey University, Palmerston North, New Zealand
Computer Science | Ph 64-6-3505799x2474 == Fax 64-6-3502259 == ZL2BOI
------------------------------------------------------------------------
http://www-ist.massey.ac.nz/moretti mailto:G.Moretti_at_massey.ac.nz
> We have a problem that is exactly as described in issue 1824
> http://subversion.tigris.org/issues/show_bug.cgi> ?id=1824 .
> This has been marked as a duplicate of issue 1634
> http://subversion.tigris.org/issues/show_bug.cgi?id=1634 ,
> which is marked as fixed.
>
> However, it looks like the problem behaviour in 1824 is still
> present in 1.03 and (I believe) in the current source
> version. Can someone update me as to the status of this?
>
> Our scenario is as follows: we have a repository with a
> number of files and directories at the top level. One of the
> directories contains large binary content files (7GB, which
> doubles to 14GB when duplicated by svn to create clean local
> copies). Many developers would like to omit this directory
> when they do checkouts (to avoid having to buy new disk drives!).
>
> As there is no "exclude" option in svn (yet?), a workaround
> would seem to be to check out the top-level non-recursively
> (to get the top-level files), then to check out the subdirs
> one by one into the top-level of the WC, omitting the content
> directory. But, this does not work because of issue 1824.
>
> I know we could restructure the directory hierarchy, but this
> would require significant changes to the build environment.
>
> Any help is appreciated. And, thanks for building a great system!
>
> Peter
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 21 07:55:43 2004