10 messages in com.perforce.perforce-userCommon Usage patterns| From | Sent On | Attachments |
|---|---|---|
| Mark...@glyphic.com | 26 Sep 1997 11:29 | |
| Paul...@radstone.co.uk | 29 Sep 1997 00:53 | |
| Mark...@glyphic.com | 29 Sep 1997 08:50 | |
| Mark...@pml.com | 29 Sep 1997 09:24 | |
| Mark...@glyphic.com | 29 Sep 1997 09:43 | |
| Brad...@email.mot.comBrad_Appleton-GBDA001 | 29 Sep 1997 09:57 | |
| Tony...@illustra.com | 29 Sep 1997 11:41 | |
| Robe...@SCRAP.de | 30 Sep 1997 01:30 | |
| Gerd...@camelot.BITart.com | 30 Sep 1997 10:46 | |
| Robe...@SCRAP.de | 01 Oct 1997 00:18 |
| Subject: | Common Usage patterns |
|---|---|
| From: | Robe...@SCRAP.de (Robe...@SCRAP.de) |
| Date: | 09/30/1997 01:30:52 AM |
| List: | com.perforce.perforce-user |
-----Original Message----- From: Mark Lentczner <markl at glyphic.com> To: PERFORCE-USER Distribution List <perforce-user at perforce.com> Date: Montag, 29. September 1997 17:52 Subject: Re: Common Usage patterns
Because I share this project with other people. And the tendenancy is for those people to just type: p4 get which would get my non-working version of b (which may not even compile at this point!). Can one submit a change and mark it in such a way that those revisions aren't considered 'head' when other users do a get?
Mark, I have exactly the same need and have solved it this way (it may seem a bit over-powered but it has proven to be a very good way). We use Perforce on our server to have a 'global' place for checked source-code which has been released by the developer. So this source-code should fit into the overall project without disturbing anything.
The developer get's this version if he starts working on a new feature. After each successful compiler run we check-in the source-code under development on the local drive of the developer (for this we use PVCS; I know it's an odd product but for this it's ok), this is done through the make-file, so the developer doesn't have to care about it. After finishing a new version (how long this ever take) the developer 'propagates' the new source-code file to the perforce server and it becomes visible to the rest.
The local version controlling is very useful because developers can make rough changes and tryout something and fallback to an older version. Sometimes the lack of discritptions is a bit a problem but the developers have a feeling in which version a change was made. The PVCS tools can be used on the archives so the version can be found...
I have talked to the perforce people to include a local version controlling which holds the archive locally on the developer machine... maybe if enough people pray for it we get it all in one product.
Robert M. Muench SCRAP EDV-Anlagen GmbH, Karlsruhe, Germany
==> Private e-mail: r.m.muench at ieee.org <== ==> ask for PGP public-key <==
When do you want to reboot today?