Committing from the command line
(This post is actually a series of feature requests, but I'd rather
not open new work items without some confirmation that these things aren't already available.) I've created a workspace that's tied to a stream, and it's time to make changes. I edit pom.xml in Emacs, save, and check the workspace status: $ scm status M pom.xml A pom.xml~ pom.xml~ is the backup file created by Emacs; *~ is on my Team's ignored resources list (checked), so I'd not expected this file to appear on the status list. I delete the file and checkin my actual change: $ scm checkin . $ scm deliver Delivering changes from "Tyto2008WS" into "Tyto 2008" No baselines to flow. Change-sets to flow: Component "Tyto" change-set: "<No comment>" Delivery was blocked by process. "Delivery was blocked by process" is quite unhelpful. The only way I see to ask for more information is with --verbose, but this switch gives me exactly the same words. How can I get the reason for the block? Giving up long enough to plug in a mouse, I fire up TeamConcert and find out that the process requires an associated work item or non-blank comment before delivering changes. This makes sense. Back at the command prompt, I guess that what I need to do is use 'scm checkin -c' to select my already checked-in change set and set the comment. I can select change-sets by UUID, but I don't see how to find out the UUID that identifies my checked-in but not delivered change. I seem to be completely stuck here, at least with the command line tool. I don't have a way to deliver the change, modify it, or back it out. I'm okay with occasionally using Team Concert during the beta, but that's not going to work for regular use. Which of these are feature requests, and which are me not understanding how to get things done? |
9 answers
mjeffcoat@us.ibm-dot-com.no-spam.invalid (mjeffcoat) wrote in news:fmjgmr
$u5s$1@localhost.localdomain: "Delivery was blocked by process" is quite unhelpful. Open work item 41340 to improve error message -- Christophe Elek Serviceability Architect IBM Software Group - Rational |
> pom.xml~ is the backup file created by Emacs; *~ is on my Team's
> ignored resources list (checked), so I'd not expected this file to > appear on the status list. We don't respect the Eclipse Team settings from the commandline. You should be able to create a .jazzignore file ignoring '*~'. The following ignore file will ignore all files in the same directory that end with a tilde. --- core.ignore=*~ --- |
The "Delivery blocked by process" error, this is because of bug 35850. The workaround is to run your RTC client and edit the process specification for your project to make all client side deliver advisors optional=true (eg, they won't run if they can't be found).
<behavior> <role id="contributor"> <operation id="com.ibm.team.scm.client.deliver"> <preconditions> <precondition optional="true" description="" id="com.ibm.team.process.deliver.requiredContent" name="IBM Copyright" overrulable="true"> <filePattern pattern=".*java"/> <requiredText text="Copyright IBM Corporation"/> </precondition> <precondition optional="true" description="" id="com.ibm.team.process.deliver.requireWorkItem" name="Require Work Item" overrulable="true"> <requires value="workitem-or-comment"/> </precondition> </preconditions> </operation> </role> </behavior> The reason is that currently our process integrations are tied to the UI, this isn't good, but I don't know the ETA on getting this fixed for 1.0 since this bug has been marked as post 1.0. |
|
Let me add a few more details "Delivery blocked by process" problem; it's not clear to me that bug 35850 is related.
1. The process advisor (?) was correct to block the delivery; I really hadn't assigned a comment to my change set. 2. When I do include a message with my change set, deliveries proceed correctly and without complaint, without making advice optional. What I wasn't able to do from the command line was to get the explanation of which rule my delivery was violating. It turns out that rule was (paraphrased) "Every change set must either be linked to a work item or have a non-blank comment." I can write a --message with the checkin command that satisfies the non-blank comment rule, but I don't see how to link a change set to a work item. Is that possible yet? |
> pom.xml~ is the backup file created by Emacs; *~ is on my Team's Thanks for the response. First, since I have essentially no Eclipse experience, it's not clear to me when the underlying platform is leaking through; it would never have occurred to me that the "Team" settings would be part of Eclipse but not Jazz. That's not something you can fix, of course -- I'm just trying to make it clear where my confusion may be coming from. Given that, though, I can't make your .jazzignore suggestion work. When I put it in a directory with a backup file, my 'scm status' now shows two added files, foo~ and .jazzignore. I've tried a couple of the various metadata directories (.jazz3 and below) and am gettting the same thing. Is is just me having this problem? The Source Control FAQ suggests that .jazzignore goes in the "root of my project"; I can't imagine where that is if not in the places I've tried. |
|
> Let me add a few more details "Delivery blocked by process"
> problem; it's not clear to me that bug 35850 is related. > 1. The process advisor (?) was correct to block the delivery; > I really hadn't assigned a comment to my change set. From my testing, all client advisors would block. I've released a change which prints a verbose log of why process fails so that we can see if it's because the advisors failed or the advisor couldn't be found. > 2. When I do include a message with my change set, > deliveries proceed correctly and without complaint, without > making advice optional. I can't explain how this would every work for you. Can you double check your process specification or tell me how you setup your project so that I can reproduce. > What I wasn't able to do from the command line was to get > the explanation of which rule my delivery was violating. This has been fixed. |
> Checking again, I discover that I was lying to you. It's not my fault, my memory was lying to me. We're both victims here. Even with a message attached to the change set, my delivery fails with the "blocked by process" error from the CLI, but can be sent without changes by Team Concert. Thank you for the clarification. |
Translating from Eclipse to command-line: a project is a top-level shared directory. If load vie the CLI and get three directories: foo/, bar/, and baz/, each one of those is a project. The .jazzignore file does not have to go in the root. The line from the FAQ that you're quoting refers to the patterns that are ignored by default (https://jazz.net/learn/LearnItem.jsp?href=content/docs/source-control/faq/index.html#How_do_I_share_a_file_that_s_ign). When used in the CLI, the .jazzignore file will prevent check-ins. If you've already checked some file in, then ignore will only prevent future check-ins. It will not remove the file from the outgoing changes. |
|
Thanks, Evan. I'm getting it now, though I still find the behavior counter-intuitive. I'm going to repeat what I've heard back to you:
I create a file called stuff~, and a .jazzignore in the same directory with a *~ pattern. $ scm status A stuff~ A .jazzignore Feature Request 1: 'scm status' should respect .jazzignore. (Filed as Enhancement 41506) I 'scm checkin .' Looking in Team Concert, I see that my changeset only includes the .jazzignore file, so stuff~ was (properly) ignored. Now that .jazzignore has been checked in, though, 'scm status' starts using the patterns in it. This took me very much by surprise (as the evolution of 41506 indicates), but that may be me trying to drag to many expectations over from Subversion. (Where status is a purely local operation.) Also: core.ignore applies the pattern to the current directory; core.global.ignore applies the pattern globally. (It seems not to matter where I put the global ignore; the "root of my project" in the FAQ was just a suggestion, not a requirement.) |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.