3 messages in com.perforce.perforce-userRe(2): offline usage with perforce?| From | Sent On | Attachments |
|---|---|---|
| Nick...@aperture.com | 30 Jun 1998 09:47 | |
| WesP...@softweyr.com | 01 Jul 1998 22:48 | |
| Jame...@perforce.com | 02 Jul 1998 09:29 |
| Subject: | Re(2): offline usage with perforce?![]() |
|---|---|
| From: | WesP...@softweyr.com (WesP...@softweyr.com) |
| Date: | 07/01/1998 10:48:28 PM |
| List: | com.perforce.perforce-user |
My hidden microphone recorded (Nick Pisarro) (nickp at aperture.com) saying: % This is an OK technique if the depot or section thereof is small and/or % you're doing your sync up via LAN. We work with a depot with 1,500 files % and connect via modem. It is not practical to find out which files have % changed by comparing them all against the depot. Many perforce users work % with depots with many thousands of files.
There aren't a lot of other ways to do it, unless you want to play with file modification times or something like that. The only reliable way to determine which files on client differ from the server is to have Perforce tell you which ones have been changed/added/deleted. This would be true of *ANY* CM system; Perforce at least helps by being relatively fast on this operation. Your problem is your connectivity, not your CM system.
As far as depots with many thousands of files, my current project, in the latest of 18 or so different active revisions, has 10,508 source files. We also have software developers in 7 offices scattered all over the continental USA.
% Doing a branch and a merge from the branch is also not the most practical % when you have a project with thousands of files. You still need to resolve % your changes and test them locally to be safe and do your final submit. I % don't quite understand how the branch helps you in that case. I don't have % that much experience using branches, however.
You don't understand how Perforce branches, using "lazy copy." The files aren't copied from the original codeline to the branch until you modify them. On the average feature-adding branch, you're probably not going to touch more than a few 10s of files, so only those files get copied to the branch. When you integrate this branch back up to the main codeline, the changes introduced on the branch are merged with any changes that were made to the main codeline. =
The files modified in the branch remain on the server for historical completeness, but effectively become dead as far as the progress of the code is concerned.
What the branching does is allow the developer(s) who're working on a feature to code to a stable base; they don't have to worry about clashing with another programmer's bug fixes while trying to get their feature up and running. Once the feature is working and stable, the branch is integrated, and any such problems can be addressed during the merge.
--- "Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes at softweyr.com
=
=20




