[p4] Workspace option: exclusive open

[Robert Cowham]

> > The drawback with single large workspaces is that people who don't 
> > know what they are doing don't to a p4 sync #0 to get rid of local 
> > files, and this can end up inflating the size of the db.have table.
> 
> Is that actually worse with one workspace vs. multiple 
> workspaces, all synced as well? I would think 300 files 
> synced to one workspace would be no worse than 100 files 
> synced to each of three workspaces. In either case, most 
> branches wouldn't be fully synced in practice and when drive 
> space gets tight, it's a helpful reminder to clean up.

You are right in that db.have contents are the same in both cases. However,
with separate workspaces it's easier to look at the modified/accessed time
and delete old/unused ones (than delete old/unused db.have entries for a
still active workspace).

> > With that amount of propagation how possible is automation?
> 
> We've tried some. It tends to fall apart for the general case 
> since each team has different requirements and there are 
> inter-product dependancies. Also, there really are no 
> resources to develop an adaptable tool (or buy one - that we 
> haven't been forced to move to CVS yet is a bit of a surprise to me).

The principles are not hard to achieve 80% of the job, leaving 20% for
manual fixing. I would suspect a worthwhile investment of your time given
the time savings - depends of course on having some level of scripting
skills available.

> One problem is refactoring. The enthusiasm for that varies by 
> team, but even in the most stodgy, a 2-3 year old code base 
> is often sufficiently different from the current branch that 
> integration is largely pro-forma with the real work done 
> essentially as an independent edit rather than a real merge.

Branch specs with special overrides take care of some of the refactoring
issues. Drawback is that the branch specs need to be kept up-to-date, but
there is some help (e.g. Tony Smith has a script in the public depot to
detect renames).

Merging codebases 2-3 years apart is certainly likely to be tricky, though -
need to make sure management is well aware of the extra cost of maintaining
potentially widely disparate releases (and thus has factored this in to
pricing to customers, and can give better resources!). I have seen lots of
bad decisions made because management didn't understand what they were
committing themselves to (and also where they took risky/bad short term
decisions in any case, even when issues were pointed out!).

Robert