[p4] Confused by 'p4 integrate' behavior.

[Weintraub, David]

I guess you could add into the integration table entries for
non-existent files. These would be files that exist in the target, but
not in the source or visa-versa. Perforce would ask you once whether you
wanted to add or delete a file on the first integration attempt, and
that answer could be stored in the integration table, so you don't get
asked again. It would involve a two-pass resolve (resolve directory
differences then the files themselves), and it would involve an overhaul
of the "p4 integration" resolve" behavior as well as changing the schema
of the integ table.

However, I can't see how renamed/moved files and directories could be
handled in this manner since Perforce "keys" file names by the full
depot path name of the file. The integ table entry would be keyed by
"from file"/"to file". When I integrate from //depot/MAIN/... to
//depot/FOO/..., there isn't any way to tell that //depot/FOO/foobar.cpp
was moved to //depot/FOO/newdir/barfoo.cpp. Also, under this scheme,
Perforce would still be required to ask (at least the first time
through) how to handle a file missing from either the source or target
directory since it wouldn't know whether the result was due to a change
in the source directory structure or target directory structure.

Plus, it would require major changes in the way the "integrate/resolve"
command would work. Right now, Perforce simply resolves all opened files
(including delete and add operations). The opened files were created in
the integrate operation. In your method, Perforce couldn't necessarily
"open" a file that was added or removed since you really don't know
whether or not to add or delete this file until you actually run the
resolve operation.

Directory versioning would be able to handle this much better. It
doesn't have to be as heavy handed as it is in ClearCase. In ClearCase,
to add a file to a directory, you must first check out the directory,
then add the file, and finally remember to check in directory back in.
This three step process is a big pain vs. the single step Perforce has.
Besides, too many times users checkout the directory, add the file, but
then forget to check in the directory to register the change with the
source archive. You end up with a file in the source archive that isn't
in any directory.

Subversion versions directories, but adding and deleting files is a
single step process like in Perforce. You simply add or delete the file,
and Subversion tracks the directory changes. That is because directories
in Subversion are lighter members of the source archive than the files
themselves. Plus, Subversion cheats because it only versions the entire
archive structure and not individual files.

There would be definite advantages to Perforce actually performing
directory versioning. During an integration/resolve, Perforce would be
able to examine the version history of the source and target directory
and determine that if a file is missing from the source or target
directory, whether this was due to a change in the target or the source
directory. That would allow Perforce to determine whether or not to add
or delete the file, or just leave it be without requiring the user to
know this information.

Directory versioning could also handle file renames and moves. Perforce
could examine the target directory's history, see that a file was
actually moved or renamed, and handle the integration/resolve from there
by performing the integration and resolve on the moved file. With
directory versioning, you eliminate the need for branch specifications.

Adding directory versioning to Perforce would be a major change, but
would not necessarily involve a complete overhaul of Perforce's depot
structure. Unlike ClearCase, you could handle directory versioning in a
more "virtual" manner. All you need is a text file in each directory
that tracks what files are in each version of a directory. Like all
other files in Perforce, it could be stored in RCS format.

Directory versioning would involve a change in the depot layout (these
special files that track the directory version would have to be added
and created). It would involve a change in the behavior of the "p4 add"
and "p4 delete" commands (since these would version this special file),
you'd have to create a "p4 mv" command (to allow this file to track file
renames and moves). And, like yours, it would involve major changes in
the way Perforce's integrate/resolve system works although with fewer
changes than the way your system would require.

The integration step would be unchanged. Perforce would still mark files
for adds and deletes the way it does now. However, Perforce would have
to perform a two pass resolve. The first pass would resolve these
directory tracking files. Resolving these directory structure file
changes would be like resolving any other text file. Perforce would find
a base version, examine the two leaves, and merge the results. You could
even have the same options ("accept simple", "accept merge", "accept
theirs", and "accept yours"). Once you resolve these special directory
files, Perforce would unedit the adds and deletes as resolved, and make
a second resolve pass for any other files that still needed to be
resolved.

Tracking directory changes in this way wouldn't change much of
Perforce's feel. Users still wouldn't add/delete or check in and out
directories (since directories still aren't first class archive
entries), and you wouldn't have the ClearCase problem with "evil twins".

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of sandy currier
Sent: Friday, October 06, 2006 5:24 AM
To: perforce-user at perforce.com
Subject: Re: [p4] Confused by 'p4 integrate' behavior.

It is still possible for Perforce to support deletes without necessarily
versioning directories.  Our enhancement requests for this have been
under the title of "support resolve-able deletes", as Steve has
referenced below.

The main point is to allow deletes and edits (and adds) to be able to be
resolved at resolve time instead of integrate time.  In the case where
there is no target file to begin with, Perforce would need to support
version #1 of a file being an action something other than an add or a
branch - specifically a delete in this case.  The resolved delete data
could be stored as a (almost) normal integration record

ClearCase supports merging deletes with versioned directories, which
though nice, does create usage artifacts.  AccuRev supports this without
versioned directories, and the usability is quite nice.
For example, when resolving a delete against an edit, one effectively
gets a "do you want to accept this delete" prompt.  When resolving a
file name change, one effectively gets a "do you want to accept this
name change" before one gets to the effective "accept theirs, yours,
etc." content prompt.  Perforce could do the same with deletes by say
scheduling a pending 'delete' resolve for that file.

I personally think that if Perforce were to support resolve-able
deletes, Perforce too would have nice usability in this area (hint
hint).

-sandy



The problem is that there is no place in the current Perforce database
to store these decisions. For example, what if I have a file in my
source branch, but not my target branch? Let's say this happened because
I deleted that file from my target branch. The first time through, I
somehow tell Perforce "Do not add this file to my target branch". Where
does Perforce store this information? It can't store it in the target
file because there is no file in my target branch. That's why we
manually have to modify the branchspec to store this information.

Maybe what we may need is an "internal branchspec". That is, when we
tell Perforce "don't add this file", this internal branchspec could keep
track that we don't want to add this file. Then, Perforce will know the
next time not to attempt to delete or add this file.

In fact, if this internal branchspec could be versioned like a file, it
could even anticipate our responses. Let's take the missing file in my
target branch. This could be for one of two reasons (okay, there's more
than two, but we'll consider two for now): I could have removed the file
from my target branch or I could have added the file to my source
branch.

Let's take the first case, and say I removed the file from my target
branch. Perforce would examine the internal branchspec, see that there
is a new version of this branchspec since the last integration, and see
that this file was deleted. It could then know, without even asking me,
that I don't want this file readded when I again integrate from the
source branch to the target branch.

Let's take the second case, and I added the file to my source branch.
Perforce would examine the branchspec, see that the file was never in my
target branch, and ask if I want to add the file. When I say "no",
Perforce would track that decision in the internal branchspec, create a
new version of the internal branchspec with that decision, and never ask
me again.

All we are now missing is a way to move files and be able to track the
move. Right now, we actually do a copy and delete which isn't quite the
same. Let's say we actually have a "move/rename" command:

    $ p4 mv foo.cpp bar.cpp

Now, my internal branchspec can actually track the move (just like you
would with your current branchspec). Next time I integrate, my internal
branchspec will let the integrate command know that the file foo.cpp in
my source branch should integrate with file bar.cpp in my target branch.

Would this work?

-----Original Message-----
From: Stephen Vance [mailto:steve at vance.com]
Sent: Tuesday, October 03, 2006 4:19 PM
To: Weintraub, David
Cc: Krzysztof Kozminski; perforce-user at perforce.com
Subject: Re: [p4] Confused by 'p4 integrate' behavior.

Full directory versioning is not necessary to solve this issue. Simple
ability to accept yours or accept theirs for deletes and adds is
sufficient. The file-based versioning can be made to handle it without
all the complexity of directory versioning (e.g. accept yours when
integrating a branch/add gives a #1 version that is a delete).

The only thing directory versioning solves is the empty directory
problem. Even rename issues can be solved without that.

Steve
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user