15 messages in com.perforce.perforce-userDepot wasting space?| From | Sent On | Attachments |
|---|---|---|
| Koht...@ntc.nokia.com | 27 Jan 1998 05:30 | |
| Laur...@perforce.com | 27 Jan 1998 09:12 | |
| Davi...@home.chat.net | 27 Jan 1998 10:08 | |
| Koht...@ntc.nokia.com | 28 Jan 1998 08:39 | |
| RobC...@within.com | 28 Jan 1998 11:07 | |
| Laur...@perforce.com | 28 Jan 1998 11:13 | |
| Koht...@ntc.nokia.com | 29 Jan 1998 07:12 | |
| Koht...@ntc.nokia.com | 29 Jan 1998 09:21 | |
| TomB...@ebc.ericsson.se | 29 Jan 1998 23:39 | |
| nic...@aperture.comnickp | 30 Jan 1998 05:13 | |
| TomM...@sybase.com | 30 Jan 1998 07:03 | |
| Koht...@ntc.nokia.com | 31 Jan 1998 11:59 | |
| Mark...@voro.lbl.gov | 31 Jan 1998 14:31 | |
| Matt...@geoworks.com | 02 Feb 1998 17:28 | |
| Koht...@ntc.nokia.com | 04 Feb 1998 04:30 |
| Subject: | Depot wasting space? |
|---|---|
| From: | Matt...@geoworks.com (Matt...@geoworks.com) |
| Date: | 02/02/1998 05:28:16 PM |
| List: | com.perforce.perforce-user |
Kohtala Marko <Marko.Kohtala at ntc.nokia.com> writes:
Sorry, I forgot to reply to this question of yours:
However, there are likely to be some outliers among our users whose particular development environments, and SCM needs, may be causing Perforce to be a resource hog. Please let us know what kinds of constraints you're running into (server disk space? client disk space? network bandwith? etc.). We really do want to stay in front of the pack performance-wise, and your feedback will help us.
Let me explain how I intended to work. I have
//depot/linux/release/2.1/... //depot/linux/own/patch1/... //depot/linux/own/patch2/... //depot/linux/own/patch3/... //depot/linux/own/patch1+2/... (patchn replaced with more descriptive name)
Sometimes I need to work on the change for some time before it is good enough to be sent to maintainers. It is not suprising for Linus to make changes to 20M worth of files in the Linux source tree in the few months that it takes to complete one patch and get it merged to the release branch. During this time, the changes in release branch need to be merged to the patch braches that are not yet merged to release branch. Since Perforce copies the changes in depot to each branch instead of just taking the new version from the source branch, these 20M of files are copied to every branch.
Before Perforce I needed to back up few latest diffs to the release. This could fit on a floppy. Now I have a 45M release branch and increasing number of own 20M branches.
I do not mind the 45M. I knew and accepted that cost. I mind the 20M per branch when there are less than 100K worth of changes.
With each of your own patches, you are working on a specific area of the system, no? Why not just branch that portion of the system? If you branch just the NFS driver, and then set up a client that gets all but the NFS driver from the release, you won't have the problem you're describing.
I agree though, that Perforce claims 'lazy copy' with branches but does not fully provide it. Ideally Perforce would delay the 'lazy copy' until an actual change is made to the file on the branch -- even if multiple 'copy from' integrations occur from the original source of the file. I agree with you and fail to see how this incomplete implementation of 'lazy copy' is optimal for performance.
We just had a major renaming occur to almost every one of our source files on our trunk. Subsequent integrations from the trunk to our various branches took a long time and now every one of our branches has their own copy of each file touched -- even though 99% of them are still identical to the trunk version. Not a big deal for us though -- our backup system can handle it fine.
--- matta