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 ..??
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.
>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.
>From: mike nicholaides [mailto:firstname.lastname@example.org]
>Sent: Friday, April 28, 2006 11:05 AM
>To: Gale, David; email@example.com
>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
>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,
>On 4/28/06, Gale, David <David.Gale@hypertherm.com> wrote:
>>mike nicholaides wrote:
>>>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
>>>Here's a simple example of what I want to do, in case the previous
>>>paragraphs are vague.
>>>I have a directory structure:
>>>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:
>>>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
>>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.
>To unsubscribe, e-mail: firstname.lastname@example.org
>For additional commands, e-mail: email@example.com
phion Information Technologies GmbH
Tel: +43 512 394545
Fax: +43 512 394545-20
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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jul 4 11:03:30 2006