[PATCH] Optional shrinking of RCS keywords in git-p4

[PATCH] Optional shrinking of RCS keywords in git-p4

[Dhruva Krishnamurthy]

Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.
New option git-p4.kwstrip set to true or false controls the behavior.

Signed-off-by: Dhruva Krishnamurthy <dhruva@ymail.com>
---
 contrib/fast-import/git-p4 |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2216cac..ac8b7f7 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -16,6 +16,9 @@ from sets import Set;
 
 verbose = False
 
+# Handling of RCS keyowrds. To ensure backward compatibility, the default
+# is to strip keywords. Default behavior is controlled here
+kwstrip = True
 
 def p4_build_cmd(cmd):
     """Build a suitable p4 command line.
@@ -975,7 +978,9 @@ class P4Sync(Command):
                 sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
                 continue
 
-            if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
+            if not kwstrip:
+		pass
+            elif stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
                 text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
             elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
                 text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
@@ -1850,6 +1855,16 @@ def main():
         (cmd, args) = parser.parse_args(sys.argv[2:], cmd);
     global verbose
     verbose = cmd.verbose
+
+    global kwstrip
+    kwval = gitConfig("git-p4.kwstrip")
+    if len(kwval) > 0:
+	kwval = kwval.lower();
+        if kwval == "false":
+            kwstrip = False
+        elif kwval == "true":
+            kwstrip = True
+
     if cmd.needsGit:
         if cmd.gitdir == None:
             cmd.gitdir = os.path.abspath(".git")
-- 
1.6.0.1.454.g63d55

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[David Brown]

On Mon, Sep 15, 2008 at 11:28:51AM +0530, Dhruva Krishnamurthy wrote:

>Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.
>New option git-p4.kwstrip set to true or false controls the behavior.

I'm a little curious about what the problem here is.  I've been
stripping keywords out of P4 and submitting changes for many years,
and never had a problem.

I'm just wondering if we're not fixing the wrong problem here.

David

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Junio C Hamano]

Dhruva Krishnamurthy <dhruva@ymail.com> writes:

> Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.

Hmm.  How are "missing hunks" caused?  Do you mean:

 - the substituted values from the expanded keywords are stripped out by
   default (with kwstrip=True) when you check out from p4;

 - when you submit your changes back, p4 side expects you to send the file
   with keywords just as it originally expanded;

and this causes the contents mismatch, leading p4 to reject your change?

The patch itself looks fine; I just wanted to make sure commit log
explains what was fixed.

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hi,

 If you have p4 files with 'ktext' enabled, it will expand RCS keywords. Here is how it goes wrong.

1. Clone from p4 with files of 'ktext' type
2. git-p4, converts "$Id:........" to "$Id$"
3. So, the file in p4 and git are different as RCS keywords are modified
4. You locally edit and commit into git a p4 file of type 'ktext'
5. The change history in your local git commit will not have any hunks to track the RCS keyword as they are not modified locally
6. Someone edits the same file on p4 and submits
7. you do a git rebase (which pulls in the new modifications and strips the RCS keyword change, p4 submit would have incremented the $Id:....$)
8. The git diffs is now not aware of the change in RCS keyword
9. You try to submit your local changes back to p4
10. Applying your local changes as patch sets will fail with missing hunks tracking RCS keyword changes

I have personally experienced more often and hence decided to dig into git-p4 and fix it. All C/C++ source code is created in our p4 repo as 'ktext' and I keep stumbling on this very often. Ideally, if they were just 'text' type in p4, I would never have seen this problem. 

-dhruva

PS: Simon Hausmann, I missed adding you in CC of the patch as my .gitconfig was still under stablizing. I apologize for that. I have finally set up my ..gitconfig with 'git-p4' identity to add you in loop when I submit.


----- Original Message ----
> From: David Brown <git@davidb.org>
> To: Dhruva Krishnamurthy <dhruva@ymail.com>
> Cc: GIT SCM <git@vger.kernel..org>; Junio C Hamano <gitster@pobox.com>
> Sent: Monday, 15 September, 2008 11:39:55 AM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
> 
> On Mon, Sep 15, 2008 at 11:28:51AM +0530, Dhruva Krishnamurthy wrote:
> 
> >Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.
> >New option git-p4.kwstrip set to true or false controls the behavior.
> 
> I'm a little curious about what the problem here is.  I've been
> stripping keywords out of P4 and submitting changes for many years,
> and never had a problem.
> 
> I'm just wondering if we're not fixing the wrong problem here.
> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



      Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hello,



----- Original Message ----
> From: Junio C Hamano <gitster@pobox.com>
> To: Dhruva Krishnamurthy <dhruva@ymail.com>
> Cc: GIT SCM <git@vger.kernel.org>
> Sent: Monday, 15 September, 2008 11:47:19 AM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
> 
> Dhruva Krishnamurthy writes:
> 
> > Modifying RCS keywords prevents submitting to p4 from git due to missing 
> hunks.
> 
> Hmm.  How are "missing hunks" caused?  Do you mean:
> 
> - the substituted values from the expanded keywords are stripped out by
>    default (with kwstrip=True) when you check out from p4;
> 
> - when you submit your changes back, p4 side expects you to send the file
>    with keywords just as it originally expanded;
> 
> and this causes the contents mismatch, leading p4 to reject your change?

Yes (you got my point ;), I have quite often stumbled in conveying things in a crisp manner (on going learning process)

> The patch itself looks fine; I just wanted to make sure commit log
> explains what was fixed.

-dhruva



      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[David Brown]

On Mon, Sep 15, 2008 at 11:56:22AM +0530, dhruva wrote:

>8. The git diffs is now not aware of the change in RCS keyword
>9. You try to submit your local changes back to p4
>10. Applying your local changes as patch sets will fail with missing hunks tracking RCS keyword changes

It sounds like you are trying to apply these as patches to a tree
which doesn't have RCS headers.  As far as I can tell, P4 completely
ignores whatever the $Id: ...$ headers happen to be expanded to at the
time of checking.  You can put garbage there, and it check in fine.

I've been checking in files for many years with stripped headers.  I
wrote a python script years ago to strip the P4 headers after Perforce
was unwilling to implement this as an option.

I guess it isn't a problem to make this optional in git-p4, but I
don't think this patch is solving the right problem.

David

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hello,



----- Original Message ----
> From: David Brown <git@davidb.org>
> To: dhruva <dhruva@ymail.com>
> Cc: GIT SCM <git@vger.kernel.org>; Junio C Hamano <gitster@pobox.com>; Simon Hausmann <simon@lst.de>
> Sent: Monday, 15 September, 2008 12:05:21 PM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
> 
> On Mon, Sep 15, 2008 at 11:56:22AM +0530, dhruva wrote:
> 
> >8. The git diffs is now not aware of the change in RCS keyword
> >9. You try to submit your local changes back to p4
> >10. Applying your local changes as patch sets will fail with missing hunks 
> tracking RCS keyword changes
> 
> It sounds like you are trying to apply these as patches to a tree
> which doesn't have RCS headers.  As far as I can tell, P4 completely
> ignores whatever the $Id: ...$ headers happen to be expanded to at the
> time of checking.  You can put garbage there, and it check in fine.

I think I now understand this better. If git-p4 is always collapsing the RCS keywords, it should not see it even while it is applying a patch. What bugs me is I got repeated hunk failures during 'git-p4 submit'. It always pointed to RCS keyword. I see it trying 'git-p4' trying to apply the patch and it fails. In the .rej file, I see the expanded RCS keyword (even without my patch that makes it optional). I then started doubting if I had done a 'p4 sync -f' which will bring in files with RCS keywords expanded. If that was the case, git would have found changed files that I have not committed.

I am a bit lost here, I will try to use this for some more time and see if I see such issues (with and without my git-p4 changes).

Thanks for making me look deeper!

-dhruva



      Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Junio C Hamano]

David Brown <git@davidb.org> writes:

> ...  As far as I can tell, P4 completely
> ignores whatever the $Id: ...$ headers happen to be expanded to at the
> time of checking.  You can put garbage there, and it check in fine.
> ...
> I guess it isn't a problem to make this optional in git-p4, but I
> don't think this patch is solving the right problem.

Hmm.  I do not do p4, but what I am guessing is that there probably is a
configuration switch on the p4 side that lets you check in files with
"$Id: garbage $" in them, while dhruva hasn't turned that switch on.

It could be (1) not flipping the switch on is a user mistake and dhruva
can just flip it to fix his problem, or (2) the policy of dhruva's project
mandates the switch to stay off, and he needs the patch to work around the
issue.

I cannot judge which is the case myself, but if the situation is the
former, we would need a documentation to suggest that magic p4 switch as a
workaround that would work for everybody without hurting anybody.  On the
other hadn, if the situation is the latter, we would need this patch in
addition to the suggestion of the magic p4 switch that the user _may_ be
able to flip depending on the project policy on the p4 side.

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Tor Arvid Lund]

On Mon, Sep 15, 2008 at 9:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> David Brown <git@davidb.org> writes:
>
>> ...  As far as I can tell, P4 completely
>> ignores whatever the $Id: ...$ headers happen to be expanded to at the
>> time of checking.  You can put garbage there, and it check in fine.
>> ...
>> I guess it isn't a problem to make this optional in git-p4, but I
>> don't think this patch is solving the right problem.
>
> Hmm.  I do not do p4, but what I am guessing is that there probably is a
> configuration switch on the p4 side that lets you check in files with
> "$Id: garbage $" in them, while dhruva hasn't turned that switch on.

Hmm.. I thought this was not a p4 problem. I think however, that
"git-p4 submit" tries to do git format-patch and then git apply that
patch to the p4 directory. In other words, I believe that git apply
fails since the file in the p4 dir has the keywords expanded, while
the patch does not. I haven't done any careful investigation, but If
my assumption is true, it sounds like dhruvas patch should work...

-Tor Arvid Lund-

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hi,
 I am going to use the patched version for sometime to see if the problem (RCS hunk) arises again. From a pure SCM interconnect perspective, it might still be good to have keyword expansion as an option. With this being an option, the data in git and p4 are same.



----- Original Message ----
> From: Tor Arvid Lund <torarvid@gmail.com>
> To: Junio C Hamano <gitster@pobox.com>
> Cc: David Brown <git@davidb.org>; dhruva <dhruva@ymail.com>; GIT SCM <git@vger.kernel.org>; Simon Hausmann <simon@lst.de>
> Sent: Monday, 15 September, 2008 4:32:32 PM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
> 
> On Mon, Sep 15, 2008 at 9:43 AM, Junio C Hamano wrote:
> > David Brown writes:
> >
> >> ...  As far as I can tell, P4 completely
> >> ignores whatever the $Id: ...$ headers happen to be expanded to at the
> >> time of checking.  You can put garbage there, and it check in fine.
> >> ...
> >> I guess it isn't a problem to make this optional in git-p4, but I
> >> don't think this patch is solving the right problem.
> >
> > Hmm.  I do not do p4, but what I am guessing is that there probably is a
> > configuration switch on the p4 side that lets you check in files with
> > "$Id: garbage $" in them, while dhruva hasn't turned that switch on.
> 
> Hmm.. I thought this was not a p4 problem. I think however, that
> "git-p4 submit" tries to do git format-patch and then git apply that
> patch to the p4 directory. In other words, I believe that git apply
> fails since the file in the p4 dir has the keywords expanded, while
> the patch does not. I haven't done any careful investigation, but If
> my assumption is true, it sounds like dhruvas patch should work...

Your assumption is true (from my understanding of the code). My doubt is, even the files in p4 folder will be from git with no RCS keyword expanded. The patch application must ideally be clean! I am confused here.

-dhruva



      Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Tor Arvid Lund]

On Mon, Sep 15, 2008 at 1:46 PM, dhruva <dhruva@ymail.com> wrote:
> ----- Original Message ----
>> From: Tor Arvid Lund <torarvid@gmail.com>
------ >8 ------
>> Hmm.. I thought this was not a p4 problem. I think however, that
>> "git-p4 submit" tries to do git format-patch and then git apply that
>> patch to the p4 directory. In other words, I believe that git apply
>> fails since the file in the p4 dir has the keywords expanded, while
>> the patch does not. I haven't done any careful investigation, but If
>> my assumption is true, it sounds like dhruvas patch should work...
>
> Your assumption is true (from my understanding of the code). My doubt is, even the files in p4 folder will be from git with no RCS keyword expanded. The patch application must ideally be clean! I am confused here.

Hmm, regarding the p4 folder - I'm pretty sure git-p4 calls "p4 sync
<depotpath>/..." in that folder before applying the patch. So those
files are whatever p4 says they are - which is with keywords
expanded...

-TAL-

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Daniel Barkalow]

On Mon, 15 Sep 2008, Junio C Hamano wrote:

> David Brown <git@davidb.org> writes:
> 
> > ...  As far as I can tell, P4 completely
> > ignores whatever the $Id: ...$ headers happen to be expanded to at the
> > time of checking.  You can put garbage there, and it check in fine.
> > ...
> > I guess it isn't a problem to make this optional in git-p4, but I
> > don't think this patch is solving the right problem.
> 
> Hmm.  I do not do p4, but what I am guessing is that there probably is a
> configuration switch on the p4 side that lets you check in files with
> "$Id: garbage $" in them, while dhruva hasn't turned that switch on.

Actually, the problem seems to be that git-p4 tries to create the modified 
file by applying the git-generated diff to the p4-provided file, and this 
fails if the context for the git-generated diff contains a keyword, since 
the p4-provided file has it expanded and git has it collapsed.

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

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hello,



----- Original Message ----
> On Mon, Sep 15, 2008 at 1:46 PM, dhruva wrote:
> > ----- Original Message ----
> >> From: Tor Arvid Lund 
> ------ >8 ------
> >> Hmm.. I thought this was not a p4 problem. I think however, that
> >> "git-p4 submit" tries to do git format-patch and then git apply that
> >> patch to the p4 directory. In other words, I believe that git apply
> >> fails since the file in the p4 dir has the keywords expanded, while
> >> the patch does not. I haven't done any careful investigation, but If
> >> my assumption is true, it sounds like dhruvas patch should work...
> >
> > Your assumption is true (from my understanding of the code). My doubt is, even 
> the files in p4 folder will be from git with no RCS keyword expanded. The patch 
> application must ideally be clean! I am confused here.
> 
> Hmm, regarding the p4 folder - I'm pretty sure git-p4 calls "p4 sync
> /..." in that folder before applying the patch. So those
> files are whatever p4 says they are - which is with keywords
> expanded...

I went through the script more closely, you are correct in your analysis. There is a call to 'p4 sync' (around line 797) before applying the commit patches (around line 809). Hence, the current patch would fix this problem of missing hunks with RCS keywords. The other approach of overwriting instead of applying the patch would also work but I feel that is a bit dangerous. It is better to fail if something goes minutely wrong than submit the wrong file (just being a paranoid defensive programmer).

-dhruva



      Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[David Brown]

On Mon, Sep 15, 2008 at 03:22:33PM -0400, Daniel Barkalow wrote:

>Actually, the problem seems to be that git-p4 tries to create the modified 
>file by applying the git-generated diff to the p4-provided file, and this 
>fails if the context for the git-generated diff contains a keyword, since 
>the p4-provided file has it expanded and git has it collapsed.

It is very likely that I've never made a change within context-lines
of a RCS header.  The files we have with these headers tend to also
comment blocks at the top that don't change after the file is created.

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

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.

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.

David

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hi,



----- Original Message ----
> From: David Brown <git@davidb.org>
> 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'.

If you have modified a file without doing a 'p4 edit' and if there is a new version of the edited file on p4 (from what you have got from a previous 'p4 sync'), 'p4 sync' will overwrite your changes (if the file does not have write perm set or if you have enabled clobbering of writable files). Whereas 'p4 sync -f' will always overwrite all unopened files if a newer version is available.

-dhruva



      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Jing Xue]

On Mon, Sep 15, 2008 at 09:12:01PM -0700, David Brown wrote:
> 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.
> 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.

How about collapsing the keywords in the _p4_ version after "p4 edit"
but before applying the patch, and just "p4 submit" the collapsed
version if patching succeeds? As pointed out earlier in this thread, p4
submit doesn't care about whether keywords are expanded or not anyway.

Cheers.
-- 
Jing Xue

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hello,



----- Original Message ----
> From: Jing Xue <jingxue@digizenstudio.com>
> To: David Brown <git@davidb.org>
> Cc: Daniel Barkalow <barkalow@iabervon.org>; Junio C Hamano <gitster@pobox.com>; dhruva <dhruva@ymail.com>; GIT SCM <git@vger.kernel.org>; Simon Hausmann <simon@lst.de>
> Sent: Tuesday, 16 September, 2008 6:28:56 PM
> Subject: Re: [PATCH] Optional shrinking of RCS keywords in git-p4
> 
> On Mon, Sep 15, 2008 at 09:12:01PM -0700, David Brown wrote:
> > A simple way to be paranoid would be something (shell-ish) like:
> >
> >   p4 print filename | collapse-keywords | git hash-object --stdin
> >
> 
> How about collapsing the keywords in the _p4_ version after "p4 edit"
> but before applying the patch, and just "p4 submit" the collapsed
> version if patching succeeds? As pointed out earlier in this thread, p4
> submit doesn't care about whether keywords are expanded or not anyway.

That is feasible but would require more changes. I still feel having an option to disable the keyword from collapsing is a move forward followed by your suggestion as a bug fix to fix the issue with 'p4 submit' when rcs keywords are collapsed. Would that be an acceptable approach?

-dhruva



      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Daniel Barkalow]

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*

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Daniel Barkalow]

On Tue, 16 Sep 2008, dhruva wrote:

> Hi,
> 
> 
> 
> ----- Original Message ----
> > From: David Brown <git@davidb.org>
> > 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'.
> 
> If you have modified a file without doing a 'p4 edit' and if there is a 
> new version of the edited file on p4 (from what you have got from a 
> previous 'p4 sync'), 'p4 sync' will overwrite your changes (if the file 
> does not have write perm set or if you have enabled clobbering of 
> writable files). Whereas 'p4 sync -f' will always overwrite all unopened 
> files if a newer version is available.  

p4 sync -f will overwrite all unopened files. It will clobber writable 
files, and it will clobber files where there isn't a newer file (it's one 
of the ways of dealing with accidentally erasing your workspace).

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[Daniel Barkalow]

On Tue, 16 Sep 2008, Daniel Barkalow wrote:

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

That is, "p4 sync <path>@<change>", of course.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[dhruva]

Hello,



----- Original Message ----
> From: dhruva <dhruva@ymail.com>
> To: Jing Xue <jingxue@digizenstudio.com>; David Brown <git@davidb.org>
> > 
> > How about collapsing the keywords in the _p4_ version after "p4 edit"
> > but before applying the patch, and just "p4 submit" the collapsed
> > version if patching succeeds? As pointed out earlier in this thread, p4
> > submit doesn't care about whether keywords are expanded or not anyway.
> 
> That is feasible but would require more changes. I still feel having an option 
> to disable the keyword from collapsing is a move forward followed by your 
> suggestion as a bug fix to fix the issue with 'p4 submit' when rcs keywords are 
> collapsed. Would that be an acceptable approach?
> 


If there are no more suggestions or objections, could we go ahead with patch? Personally, I would love to start seeing my small contributions getting into mainline and hence the shameless eagerness :)
-dhruva


      Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/