[p4] Usefulness of "file spec" integrations

[Raja Aluri]

Directory versioning and dynamic branches were the two sorely missed
features, when I moved from clearcase to Perforce.
With dynamic branches, at least one can argue that, it comes with complexity
and its own drawbacks. (Because of an intermediate filesystem)

However, directory versioning, I am not quite sure why they don't get it.
I spoke with few of the perforce people, including Christopher Seiwald in one
of the user conferences in Las Vegas 4 years ago.
They tried to convince me that 'directory versioning' was not required. I
left the conversation thinking one of us don't get it.
However, as part of my job, I deal with code lines that are pretty big and
complex products. More often than not people want to refactor and relocate
code as the code matures.
It's very painful to deal with these code refactorings, if you have multiple
branches all developing for the same release or the next release.
I learned to live with it, by paying special attention to the refactoring
branches and the timing of when they can come in into the integration branch.
I always feel, this is a sorely missing feature.
As I said before, maybe I don't get it. If somebody can enlighten me why not
having this feature is not a big deal, which would be great.

Thanks
Raja Aluri
-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of David Weintraub
Sent: Wednesday, September 19, 2007 4:37 AM
To: perforce-user at perforce.com
Subject: Re: [p4] Usefulness of "file spec" integrations

I have always looked at a branchspec as a workaround due to the fact
that Perforce doesn't track directory changes, file moves, or renames.
There has to be some way to track these changes when you merge the
differences between two branches, and in Perforce, you do it manually
via a branchspec.

In other version control systems like ClearCase that do track these
changes, you don't have the concept of a branchspec because the
program knows that you moved a file from directory "A" to directory
"B", or that you deleted the file, or its name was changed.

I actually think this is one of the weaknesses of Perforce. This
manual tracking is error prone. You have to remember which branchspec
was used, to modify the branchspec when you change the directory
structure, and to make sure the changes you put in the branchspec are
accurate. It would be nice if Perforce could actually version
directories.

One of the things that Perforce needs is a true "move" command and a
true "copy" command (integrate/delete combination doesn't work in this
respect.) Then Perforce needs to track the "adds" and "deletes" on a
per directory basis. After that, we could pretty much say goodbye to
branchspecs.

On 9/19/07, Robert Cowham <robert at vaccaperna.co.uk> wrote:
> I sometimes mention to users that the word "branch" is used in 3 ways:
>
> - as the verb "to branch" which "copies" files in a codeline to a different
> codeline.
>
> - as a noun meaning a codeline
>
> - as a noun meaning the Perforce entity more fully called a branch spec.
>
> The perforce "integrate" command will both branch (in verb sense above) and
> propagate changes between codelines (merge). Steve's definition below is
> very good.
>
> Running the integrate command specifying (via -b flag on command line) a
> perforce branch spec with N view mappings is just a short hand for the
> equivalent N filespec integrations using the source/target pairings in the
> branch spec (if no exclude lines present).
>
> Note that creating a branch spec does not of course do the integrate, i.e.
> it doesn't create the new codeline. It is like declaring the intention to
> create the new codeline. Very similar to creating a new client workspace
> spec - after creation you starting syncing it and then using it.
>
> The other thing is that if you delete the branch spec, the integrates that
> were done with it remain done (again like submitted changelists remain
> submitted even when the client workspace has been deleted).
>
> Advantages of branch specs include:
>
> - multiple lines (to achieve the equivalent in filespec integration
requires
> N commands)
> - avoidance of typos - very easy to accidentally create a new codeline
> instead of propagating changes due to a typo in target files
> - 2-way usage (with reverse option)
> - useful description
> - possible exclude view options - this is hard to do with filespec
> integration - you have to integrate and revert - easy to forget.
> - train your users to not propagate changes (via integrate) if a branch
spec
> doesn't exist. Thus you can then delete branch specs for old (retired)
> codelines, and avoid any accidental updates (this is also achievable via
> protections etc).
>
> Advantages of filespec integration:
>
> - quicker for one time operations
> - available via drag-and-drop in P4v (though this can also be dangerous -
if
> you drop on wrong place)
>
> Does that help?
>
> Personally while I think the functionality available in Perforce is very
> good in this area, I do think that the terminology used (and names of
> commands and entities) is not as clear as it could be (don't get me on to
> the "yours/theirs" stuff in resolving integrates!). For reasons of
backwards
> compatibility on the command line (API), they aren't going to change it (as
> far as I know). Note though that P4V now talks about workspaces whereas the
> underlying command is "p4 client", so there is movement towards better
> terminology.
>
> It is not an easy thing to decide how to handle this. Perforce are to be
> congratulated for the backwards compatibility thing (1997 clients talk
> happily to 2007 servers for the basics!), but the downside is that some
less
> than optimal early decisions hang in there confusing a whole new set of
> people (and of course one hopes that the number of users keeps increasing
so
> that the problem keeps getting bigger not smaller!).
>
> Robert
>
> > An integration in Perforce is a means of migrating changes
> > from one part of the repository to another. If the target of
> > the integration does not yet exist, you are "branching" (i.e.
> > creating new content, which can also be used as a micro-scale
> > copy operation). If not, it's a "merge" (i.e. setting up for resolve).
> >
> > Ok, I think this clears things up for me. It's too bad this
> > paragraph isn't at the start of one of the chapters. :-)
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


-- 
--
David Weintraub
qazwart at gmail.com
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user