12 messages in com.perforce.perforce-userPromotion/SCM models| From | Sent On | Attachments |
|---|---|---|
| Jeff...@uplanet.com | 10 Jun 1997 14:24 | |
| Clay...@stac.com | 11 Jun 1997 10:41 | |
| Jeff...@uplanet.com | 11 Jun 1997 11:28 | |
| Paul...@radstone.co.uk | 12 Jun 1997 00:52 | |
| Gerd...@BITart.com | 12 Jun 1997 01:00 | |
| Paul...@radstone.co.uk | 12 Jun 1997 03:34 | |
| Wayn...@ichips.intel.com | 12 Jun 1997 08:13 | |
| Jeff...@uplanet.com | 12 Jun 1997 08:20 | |
| Nick...@navio.com | 12 Jun 1997 09:40 | |
| Clay...@stac.com | 12 Jun 1997 10:06 | |
| Clay...@stac.com | 12 Jun 1997 10:28 | |
| Jeff...@uplanet.com | 12 Jun 1997 10:30 |
| Subject: | Promotion/SCM models |
|---|---|
| From: | Jeff...@uplanet.com (Jeff...@uplanet.com) |
| Date: | 06/12/1997 10:30:35 AM |
| List: | com.perforce.perforce-user |
At 09:40 AM 6/12/97 -0700, you wrote:
One other problem, although somewhat minor, with labels:
Say you have a file called 'foo.c' and one called 'bar.c'. The tree gets labeled. Later, you delete 'bar.c', and then rename 'foo.c' to 'bar.c' for release 2.0. I don't believe Perforce can handle such a renaming problem correctly, although I haven't experimented with 97.2 yet. I know this is an odd situation, but with large code bases, problems like this are bound to arise.
I'm not sure, but I think that it will play out as follows: bar.c version 1 - initial version bar.c version 2-N - edited/checked-in versions bar.c version N+1 - deletion of bar.c Now, if you rename foo.c using the tech note on renaming, I *think* that you'll now see bar.c version N+2 - branch (new version) So if the original "bar.c" is in a label, it'll be a revision in the range [2,N+1] so that shouldn't be a problem.
-Jeff