You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mark Ryan <m....@phion.com> on 2006/07/04 09:03:37 UTC
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 <Da...@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
Re: Partial checkouts on a huge project
Posted by Mark Ryan <m....@phion.com>.
Erik Huelsmann wrote:
> On 7/4/06, Mark Ryan <m....@phion.com> wrote:
>
>>
>> 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 ..??
>
>
> We're looking for people with time and skills to work on the issue of
> non-recursive checkouts. If you have a look at the dev@ archives,
> there's some past discussion to work with.
>
> Please join dev@ and help us out!
>
> Oh the answer to your question: we don't have enough people to address
> all priorities...
>
> bye,
>
> Erik.
Ah time - a little more for all of us would be very nice...!! I will
look around on dev@ and update myself on the latest news.
Cheers
Mark.
--
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
Re: Partial checkouts on a huge project
Posted by Erik Huelsmann <eh...@gmail.com>.
On 7/4/06, Mark Ryan <m....@phion.com> wrote:
>
> 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 ..??
We're looking for people with time and skills to work on the issue of
non-recursive checkouts. If you have a look at the dev@ archives,
there's some past discussion to work with.
Please join dev@ and help us out!
Oh the answer to your question: we don't have enough people to address
all priorities...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org