On Mon, 15 Sep 2008, David Brown wrote: > On Mon, Sep 15, 2008 at 03:22:33PM -0400, Daniel Barkalow wrote: > > >I think the right solution is for git-p4 to check that p4 thinks the file is > >the correct file and then simply replace it rather than trying to generate > >the right result by patching. To be a bit more careful, git-p4 could check > >that the contents it's replacing actually would exactly match the git > >contents if the keywords were callapsed (if the p4 setting is to use keywords > >in this file). > > Part of the problem is that p4 isn't very good at knowing whether > files have changed or not. 'p4 sync' will update the file _if_ if > thinks your version is out of date, but it does nothing if someone has > locally modified the file, hence the need for the 'p4 sync -f'. I think losing those changes are what we're trying to be careful to avoid. What matter for making the submission correctly is that p4 think that your version is the version you want to replace, and that the file contents are what you want it to end up with. > A simple way to be paranoid would be something (shell-ish) like: > > p4 print filename | collapse-keywords | git hash-object --stdin > > and make sure that is the version we think the file should have > started with. I think we're really just making sure we didn't miss a > P4 change that someone else made underneath, and we're about to back > out. p4 keeps track of which revision of each file you have synced to in your client (so that it can fail to update it sometimes, as you mention above), and will complain if the synced-to version isn't the latest when you try to submit. That's how it avoids having people accidentally back out each other's changes in ordinary operation. As long as we can be sure that the client hasn't been synced to a later version than what the parent of the commit we're submitting is an import of, which should be done with "p4 sync <changenumber>", rather than trying to spot check for having accidentally acknowledged more p4 history than we've accounted for. > Even this isn't robust from p4's point of view. The p4 model is to do > a 'p4 edit' on the file, and then the later 'p4 submit' will give an > error if someone else has updated the file. This would require using > p4's conflict resolution, and I'm guessing someone using git-p4 would > rather abort the submit and rebase. p4 doesn't let you submit files that you don't do a "p4 edit" on (or an equivalent like add), so we can't help but do it correctly (assuming that we haven't synced to a later version that the parent, of course). If you get an error on the submit, you just revert everything you editted, rebase the git side, and try again (sync to the new parent of the git commit, edit the files, replace with the git content, and submit). -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
