[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Problem with non-recursive checkouts

From: Giovanni Moretti <Giovanni_at_reflections.co.nz>
Date: 2004-05-22 02:11:48 CEST

> Thanks for the excellent suggestion -- I hadn't thought of
> this approach.
>
> However, does this get us around the problem of the files (as well as
> the directories) in the top-level directory?

No - I think that is still a problem. For me it's OK - the only top level
files are shortcuts (windows links) to the files in the folders below, but
in the general case, I think it leaves the files out of the picture UNLESS:

  1. it's possible to create a NON-Recursive "Externals" - which
     I don't think is currently possible but certainly reasonable!

  2. you can explicitly checkout non-recursively (-N from memory)
     the top level directory contents into the current workspace.
     CVS was happy to have checked out contents from several
     sources - not sure (apart from "externals" about SVN).

RATS - just realised the -N will certainly get the files but also ALL the
top level directories (which was what "externals" was trying to avoid), so
neither of (1) or (2) will work.

Bottom line is NO. Your original request - excluding directories - seems to
be the only reasonable solution.

Cheers
Giovanni

     

>
> -----Original Message-----
> From: Moretti, Giovanni [mailto:G.Moretti@massey.ac.nz]
> Sent: Fri 21/05/2004 06:55
> To: ptoft@blueyonder.co.uk
> Cc: dev@subversion.tigris.org
> Subject: RE: Problem with non-recursive checkouts
>
>
>
> 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@massey.ac.nz
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 22 02:12:24 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.