You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by we...@tigris.org on 2009/05/07 09:48:36 UTC
Minimize the size a read-only working copy
I'm a beta tester for a software project written in Perl, in which I have no repository write ability. Using SVN is convenient and minimizes the bandwidth and time needed for getting updates. But at the expense of a lot of disk space.
I have no need to ever revert changes or update to old revisions. One of the things making the working copy so large are the .svn-base files. Is there any way to operate without these files and still be able to do svn updates without them?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2092632
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Minimize the size a read-only working copy
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, webpost@tigris.org!
> I'm a beta tester for a software project written in Perl, in which I have no
> repository write ability. Using SVN is convenient and minimizes the
> bandwidth and time needed for getting updates. But at the expense of a lot
> of disk space.
> I have no need to ever revert changes or update to old revisions. One of
> the things making the working copy so large are the .svn-base files. Is
> there any way to operate without these files and still be able to do svn
> updates without them?
I have similar requirements in one place, for which I wrote deployment script.
This may help you too.
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1582002
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 07.05.2009, <23:06>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2099242
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Minimize the size a read-only working copy
Posted by Bob Archer <Bo...@infor.com>.
> On Thu, May 7, 2009 at 11:48, <we...@tigris.org> wrote:
> > I'm a beta tester for a software project written in Perl, in which I
> have no repository write ability. Using SVN is convenient and minimizes
> the bandwidth and time needed for getting updates. But at the expense of
> a lot of disk space.
> You'll need to keep track of which revision you're up-to-date with.
> (LAST_UPDATE) for the next time you go get changes.
> This probably won't work if there are renames and deletes.
>
> Sounds like a pain.
Agreed. But really, how much space are you talking about here? Perhaps this will help?
http://www.newegg.com/Product/Product.aspx?Item=N82E16822152101
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2094928
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Minimize the size a read-only working copy
Posted by "B. Smith-Mannschott" <bs...@gmail.com>.
On Thu, May 7, 2009 at 11:48, <we...@tigris.org> wrote:
> I'm a beta tester for a software project written in Perl, in which I have no repository write ability. Using SVN is convenient and minimizes the bandwidth and time needed for getting updates. But at the expense of a lot of disk space.
>
> I have no need to ever revert changes or update to old revisions. One of the things making the working copy so large are the .svn-base files. Is there any way to operate without these files and still be able to do svn updates without them?
No.
You might be able to do something with the following ideas though:
svn export will give you a copy of the sources without .svn directories.
You'll need to make a note of the actual revision exported.
You can use svn diff to get the changes since your last update as a patch.
svn diff -rLAST_UPDATE:HEAD
And apply those with patch to your exported local copy using patch.
You'll need to keep track of which revision you're up-to-date with.
(LAST_UPDATE) for the next time you go get changes.
This probably won't work if there are renames and deletes.
Sounds like a pain.
// Ben
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2092970
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Minimize the size a read-only working copy
Posted by Chris Frost <ch...@frostnet.net>.
On Thu, May 07, 2009 at 02:48:36AM -0700, webpost@tigris.org wrote:
> I'm a beta tester for a software project written in Perl, in which I have no repository write ability. Using SVN is convenient and minimizes the bandwidth and time needed for getting updates. But at the expense of a lot of disk space.
>
> I have no need to ever revert changes or update to old revisions. One of the things making the working copy so large are the .svn-base files. Is there any way to operate without these files and still be able to do svn updates without them?
If you are running Mac OS X or Linux you might checkout scord
(http://scord.sf.net/): it stores an unmodified svn checkout without
the working copy space overheads.
--
Chris Frost
http://www.frostnet.net/chris/
Re: Minimize the size a read-only working copy
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 7, 2009, at 04:48, webpost@tigris.org wrote:
> I have no need to ever revert changes or update to old revisions.
> One of the things making the working copy so large are the .svn-
> base files. Is there any way to operate without these files and
> still be able to do svn updates without them?
As Ben said, this is not currently possible. These two enhancement
requests have already been filed:
"allow working copies without text-base/":
http://subversion.tigris.org/issues/show_bug.cgi?id=525
"Store text-base compressed":
http://subversion.tigris.org/issues/show_bug.cgi?id=908
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2093246
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].