[p4] Confused by 'p4 integrate' behavior.

Sun Oct 8 14:44:05 PDT 2006

David --

Taking this approach would not require two passes. Things would still be 
keyed by file name and it would resolve them file by file. After all, 
add and delete are still operations on individual files, even if you do 
them in bulk. It shouldn't require changes to the integed table. It 
should only require additional values to the "how" field. There would 
have to be some sort of warning when integrating an add or delete into a 
file that is open for edit, as those could potentially cause file 
contents to be lost.

Perforce would still "open" the target file in the same way that it 
"opens" a file that is being deleted or added the conventional way.

In this scheme, Perforce would always have to ask the user on the first 
integration. Just because there is a structural change doesn't mean it 
has to propagate. That would still be up to the user and needs to be.

None of this would solve the rename issue, but we never suggested it 
would. In my opinion, that still does not require directory versioning. 
However, handling renames better does require a formal "move" operation 
(probably another "how" in the integed table and some major changes to 
the integration algorithm) and probably requires separation of storage 
from naming in a manner like a real file system handles things. this is 
now the Unix inode system works, which is what ClearCase emulated out of 
necessity in the mvfs drivers.

Steve

Weintraub, David wrote:
> 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
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   