18 messages in com.perforce.perforce-user[p4] Updating multiple clientspecs wi...| From | Sent On | Attachments |
|---|---|---|
| Mike Castle | 23 Apr 2001 11:13 | |
| Steve Bennett | 23 Apr 2001 12:14 | |
| Matthew Rice | 23 Apr 2001 12:15 | |
| Mike Castle | 23 Apr 2001 13:22 | |
| Steve Bennett | 23 Apr 2001 15:00 | |
| Jeremy Russell | 23 Apr 2001 15:13 | |
| Mike Castle | 23 Apr 2001 15:32 | |
| Jeremy Russell | 23 Apr 2001 15:37 | |
| Jeff A. Bowles | 23 Apr 2001 15:40 | |
| Dave Lewis | 23 Apr 2001 15:49 | |
| Jeremy Russell | 23 Apr 2001 15:49 | |
| Stephen Vance | 23 Apr 2001 15:53 | |
| Dave Lewis | 23 Apr 2001 15:56 | |
| Stephen Vance | 23 Apr 2001 16:02 | |
| Matthew Rice | 23 Apr 2001 16:24 | |
| Dave Lewis | 23 Apr 2001 16:26 | |
| Mike Castle | 23 Apr 2001 16:37 | |
| Steve Bennett | 24 Apr 2001 07:41 |
| Subject: | [p4] Updating multiple clientspecs with complex views |
|---|---|
| From: | Mike Castle (mcas...@yy.com) |
| Date: | 04/23/2001 11:13:03 AM |
| List: | com.perforce.perforce-user |
On Mon, Apr 23, 2001 at 01:19:20PM -0400, Steve Bennett wrote:
A discussion has been going around our company on the best approach to handling our clientspecs. We have some fairly complex views, which are used by quite a few clientspecs. The problem we have is if one user needs to change the view, he has to go change it in EVERY clientspec using that view, and we've often had mistakes doing that. Complicating matters are some clientspecs that, in addition to the normal contents of a given view, have some extra lines mapping in some other directories (or cutting out others).
I have decide that this way lies madness.
You have to do versioning of the client specs as well as the source. And that's just too much room for error.
What we going towards is a single client view per project. Everything you need for that project is under that heirarchy.
If you have subprojects, that need focused work (ie, libraries that can be developed standalone without needing the rest of the project), then views can be made that focus on that.
But trying to bring in bits and pieces from various locations into a single cohesive environment seems like it is more trouble than it's worth.
mrc