11 messages in com.perforce.perforce-user[p4] Perforce database size | From | Sent On | Attachments |
|---|---|---|
| Dale Johnson | 08 Dec 2000 09:29 | |
| Jeff A. Bowles | 08 Dec 2000 11:20 | |
| Dave Lewis | 08 Dec 2000 12:20 | |
| Dave Lewis | 08 Dec 2000 13:01 | |
| piaw...@escalate.com | 08 Dec 2000 14:55 | |
| Michael Go | 08 Dec 2000 15:26 | |
| Richard Geiger | 08 Dec 2000 15:52 | |
| Dave Lewis | 08 Dec 2000 16:13 | |
| Michael Go | 08 Dec 2000 16:21 | |
| Richard Geiger | 08 Dec 2000 16:44 | |
| Gareth Rees | 09 Dec 2000 12:40 |
| Subject: | [p4] Perforce database size ![]() |
|---|---|
| From: | Richard Geiger (rm...@netapp.com) |
| Date: | 12/08/2000 04:44:31 PM |
| List: | com.perforce.perforce-user |
Yipes, I should have anticipated people jumping down my throat on this.
No larnyx leaping intended! I'm really just curious whether any has in fact established a process in which "noncohenerently synced" sets of sources were routinely used.
---
BTW, we have a useful thing called "cli_snap" that preserves in a compact archive form the entire state of a client workspace, including non only the have list, but also the state WRT integrations scheduled (and, for those that have been, integrations resolved), files open for edit, and the state of user edits. A companion thing ("cli_restore"), can restore all of the client workspace state from the archive.
I've found it very useful lately where I've been working in the source tree for some tool I maintain, with a big feature development in progress; then some request to make a small change to the tool arrives. I cli_snap the state of my work, revert the client, make the small change, submit it, cli_restore my bigger change in progress, sync/resolve it (to pick up the smaller change I just submitted), and go on.
This is useful in client workspaces that have lots of other context (beyond just the revisions of Perforce-controlled files), i.e, where just setting up a new "workspace" would be a pain, since it involves much more than just setting up a new Perforce client workspace.
It also provides a nice way of "checkpointing" work in a client workspace, without submiting anything to perforce (or having to make a private branch into which to checkpoint things you don't yet want to inflict upon others).
Thanks
- rmg
Received: from iron.digitalanvil.com (mail.digitalanvil.com [208.10.150.1]) by frankenrouter.perforce.com (8.9.3/8.9.1) with ESMTP id OAA80928 for <perforce-user at perforce.com>; Fri, 8 Dec 2000 14:50:13 -0800 (PST) Received: by iron.digitalanvil.com with Internet Mail Service (5.5.2650.21) id <X9HLS756>; Fri, 8 Dec 2000 16:49:44 -0600 Message-ID: <8744DF3002FBD011BDDF000092970B460122B8A9 at iron.digitalanvil.com> From: Paul Bleisch <pbleisch at digitalanvil.com> To: "'perforce-user at perforce.com'" <perforce-user at perforce.com> Date: Fri, 8 Dec 2000 16:49:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [p4] Perforce integration in VS.NET? Sender: perforce-user-admin at perforce.com Errors-To: perforce-user-admin at perforce.com X-BeenThere: perforce-user at perforce.com X-Mailman-Version: 2.0beta2 Precedence: bulk List-Id: Discuss Perforce with other users <perforce-user.perforce.com>
Is there a plan to upgrade the perforce MS IDE integration support for VisualStudio.NET? There are some new features in the integration like support for disconnected development.
Paul
Received: from scribe.pobox.com (scribe.pobox.com [208.210.124.35])
by frankenrouter.perforce.com (8.9.3/8.9.1) with ESMTP id OAA80899
for <perforce-user at perforce.com>; Fri, 8 Dec 2000 14:47:07 -0800 (PST)
Received: from JABHOME.piccoloeng.com
(adsl-216-103-104-190.dsl.snfc21.pacbell.net [216.103.104.190])
by scribe.pobox.com (Postfix) with ESMTP
id 09AB632587; Fri, 8 Dec 2000 17:47:10 -0500 (EST)
Message-Id: <4.3.2.7.2.20001208143837.019b6298 at shell9.ba.best.com>
X-Sender: jbowles at shell9.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 08 Dec 2000 14:43:08 -0800
To: Dave Lewis <dlewis at vignette.com>
From: "Jeff A. Bowles" <jab at piccoloeng.com>
Subject: Re: [p4] Perforce database size
Cc: perforce-user at perforce.com
In-Reply-To: <200012082101.PAA00529 at medusa.vignette.com>
References: <4.3.2.7.2.20001208110334.019a00c8 at shell9.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: perforce-user-admin at perforce.com
Errors-To: perforce-user-admin at perforce.com
X-BeenThere: perforce-user at perforce.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Discuss Perforce with other users <perforce-user.perforce.com>
At 03:01 PM 12/8/2000 -0600, you wrote:
Of course, I had loads of labels and later used a more efficient mechanism for tracking releases...
Hey, Jeff, what did you end up doing in place of labels? We use 'em mainly because my mgr was used to them from CVS I think, and also because we can look at the list of labels and pick the right thing to use for a branch, etc. I would rather use changenumbers, but it would be nice to have some useful name to tag them with.
I agree with that last part: a number is harder to remember than a name. The way around this is to embed the change number into the built executable somehow, and then don't bother to remember the change number since the executable itself will tell you if you need to know it.
My solution - which I didn't arrive at until I saw it used as part of a build system - was to run: p4 changes -m1 -s submitted //depot/codelinename/... to get the number of the most recent [submitted] change in my codeline that I was building, and not only "p4 sync" to that change number but also to put that number into a "version.h" file that would be compiled into the program. That's how "programname -version" is able to print out the change number that will exactly recreate the source that built it - and the generated "version.h" needn't be checked in since it's derived in this way.
-Jeff Bowles
ps. I believe I started adding "-s submitted" when James Strickland pointed out that omitting it might give me pending changes that really would just be a distraction (and wrong).
Received: from mx.yellow.bonsai.com (eville4-fxp3.parker.net [206.14.51.86])
by frankenrouter.perforce.com (8.9.3/8.9.1) with ESMTP id JAA78583
for <perforce-user at perforce.com>; Fri, 8 Dec 2000 09:44:20 -0800 (PST)
Received: from discovery.iss-oxygen.co.uk (discovery.iss-oxygen.co.uk
[194.203.248.65])
by mx.yellow.bonsai.com (8.9.3/8.9.3) with ESMTP id EAA20205
for <perforce-user at perforce.com>; Fri, 8 Dec 2000 04:15:37 -0800
Received: by DISCOVERY with Internet Mail Service (5.5.2650.21)
id <XCQFY39T>; Fri, 8 Dec 2000 12:18:08 -0000
Message-ID: <606AA1B5575AD411BD8300C04FC12B320A9A7C at DISCOVERY>
From: Abe Crabtree <abe.crabtree at aspective.com>
To: "'perforce-user at perforce.com'" <perforce-user at perforce.com>
Date: Fri, 8 Dec 2000 12:18:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Subject: [p4] PVCS to Perforce Migration
Sender: perforce-user-admin at perforce.com
Errors-To: perforce-user-admin at perforce.com
X-BeenThere: perforce-user at perforce.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Discuss Perforce with other users <perforce-user.perforce.com>
Has anyone brought this off? I saw an email about it dated a few years ago but can't seem to find any further word,
Thanks for any info,
Regards,
Abe




