Re: Partial checkouts on a huge project

Just been going through emails from way back and came across this thread
regarding partial checkouts in large projects. We have exactly the same
problem and it is a serious problem for us in using Subversion (to be
honest if budget would allow, for this one problem I would switch to a
tool suited to larger development, eg. ClearCase).

Why can't the 'hack' suggested below be implemented to fix issue #695
which (I think) raises this exact issue and has not (apparently) been
looked at or updated in quite some time..

Just a thought ..??

Cheers

Mark.

Byron Whitlock wrote:

>You can do it the hacky way by
>
>1) Do a non recursive checkout of /trunk.
>2) Edit trunk/.svn/entries
>2a) Add a directory entry for tools: <entry name="Tools" kind="dir"/>
>
>3) Do a non recursive checkout of tools into trunk/tools
>4) Edit /trunk/tools/.svn/entries
>4a) Add a directory entry for common: <entry name="Common" kind="dir"/>
>
>5)Do a non recursive checkout of common into trunk/tools/common.
>6)Edit /trunk/tools/common/.svn/entries
>6a)Add a directory entry for tools: <entry name="drill" kind="dir"/>
>
>Go back to the trunk and "svn up" will update only the directories and files
>you've checked out.
>It feels hackly, but it does exactly what you are looking for.
>
>-----Original Message-----
>From: mike nicholaides [mailto:mike.nicholaides@gmail.com]
>Sent: Friday, April 28, 2006 11:05 AM
>To: Gale, David; users@subversion.tigris.org
>Subject: Re: Partial checkouts on a huge project
>
>
>Yeah, I thought about recursively doing non-recursive checkouts, but
>that's a pain.
>
>Another problem that I forgot to mention was that when you I have a
>huge project, svn status and commits take a really long time. I was
>considering making a super-simple web-based mechanism to view the
>status, commit, update, etc. So, I would ideally want it to be a
>quick operation.
>
>Well, if I can't find an elegant solution for the my problem, I will
>do what you suggested, David. Thanks.
>
>Anyone got any bright ideas?
>
>Thank you all,
>Mike
>
>On 4/28/06, Gale, David <David.Gale@hypertherm.com> wrote:
>
>
>>mike nicholaides wrote:
>>
>>
>>>Hey guys,
>>>
>>>I hope y'all can help me out. I've been googling and reading the
>>>archives of this list for about a week now.
>>>
>>>I have a huge intranet project that I want to put under version
>>>control. The problem I've run into is that the whole project is 1.3
>>>GB, which means that checking out the whole project, even on the same
>>>machine as the repository, takes forever.
>>>
>>>Checking out sub directories won't work, because they rely on the
>>>parent directories. Non-recursive checkouts of directories doesn't
>>>work either, because I can't recursively commit from a non-recursive
>>>checkout.
>>>
>>>Here's a simple example of what I want to do, in case the previous
>>>paragraphs are vague.
>>>
>>>I have a directory structure:
>>>
>>>trunk/
>>> tools/
>>> common/
>>> hammer/
>>> drill/
>>> chisel/
>>> custom/
>>> cde24/
>>> abc92/
>>> customers/
>>> projects/
>>>...
>>>
>>>Now, say I want to work in "drill" directory. The project depends on
>>>files in the parent, grandparent and ancestor directories.
>>>
>>>So, I want my check out to look like:
>>>trunk/
>>> tools/
>>> common/
>>> hammer/
>>>And, I want trunk, tools, common, and hammer to have all their files
>>>checked out, but none of the directories (except hammer should have
>>>all child directories checked out).
>>>
>>>Does this make sense at all?
>>>
>>>What do I do?
>>>
>>>
>>Standard advice is to do the initial checkout (which, as you say, will
>>be fairly hefty); after that point, you shouldn't need to do any full
>>checkouts again--just updates, switches, etc., which will all be fairly
>>fast.
>>
>>Alternatively, you could do a non-recursive checkout and then update
>>each sub-folder individually, spreading the network load across several
>>commands, but this obviously requires more baby-sitting.
>>
>>-David
>>
>>
>>
>
>
>--
>http://ablegray.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>

-- 
Release Manager
phion Information Technologies GmbH
Eduard-Bodem-Gasse 1
A-6020 Innsbruck
 
 Tel:  +43 512 394545
 Fax:  +43 512 394545-20
Mail:  m.ryan@phion.com
 URL:  www.phion.com
 
_______________________________________________________________
This information is confidential and intended solely for the use of the named addressee(s). If you are not the named addressee, any disclosure, copying, distribution or retention of this e-mail is prohibited, may be unlawful and violating attorney/client privilege. If you are not the intended recipient, please inform us immediately and refrain from taking any other action in reliance to this e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org