[p4] Workspace option: exclusive open

[Ivey, William]

> 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).

Granted, though most of my users wouldn't know how to do
that. They will, however, unsync a branch/directory they
don't remember needing in a while in order to free up
drive space.

Since so many branches stay in use for two years or more,
deleting unused clients would be an annual thing, more or
less.

> depends of course on having some level of scripting
> skills available.

There's the rub. I write a LOT of script lines every week
already and don't have a lot of bandwidth left over most
weeks. (I'm the resident bourne shell and perl guru, mostly
because no one else wants to.)

> Drawback is that the branch specs need to be kept up-to-date

There's the other rub :-)

> need to make sure management is well aware of the extra cost
> of maintaining potentially widely disparate releases

We had one customer single-handedly keep a code line alive for
two years after official EOL because they couldn't take the
risk of upgrading for that long. (I think their upgrade
approval and planning process alone took most of one year.)
Not only did we have to maintain that code, we had to keep
a couple of antique build machines alive to build it on.

-Wm


-----Original Message-----
From: Robert Cowham [mailto:robert at vaccaperna.co.uk] 
Sent: Monday, September 17, 2007 7:04 AM
To: Ivey, William; perforce-user at perforce.com
Subject: RE: [p4] Workspace option: exclusive open

> > 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