Jump to content


Pre-commit review oddities

swarm

  • Please log in to reply
5 replies to this topic

#1 jefftharris

jefftharris

    Member

  • Members
  • PipPip
  • 14 posts

Posted 03 July 2013 - 07:53 PM

I am looking to replace our ageing Codestriker code review system with Swarm.  I have it installed, and it appears to be functioning ok.  However, I am experiencing some odd issues trying to use pre-commit reviews.

I edit some files and do a 'p4 shelve' to create the review as described in the documentation.  If I put "[review]" in the shelve description, I see the shelved changelist show as a review.  So far, so good.

If I look at the pending changelists, I see the shelved change and also one created by Swarm for the review (I guess).  Is this normal?  Doing a p4 describe on the changelist, I see the same description but no affected files.

The review seems to work ok regarding comments and other users joining.

However, when I click on the "Approve and commit" button, I consistently get errors indicating that there are no files to submit.  I sometimes also get another pending changelist created by Swarm.  I attribute the error to the Swarm changelist not having any affected files to submit, but that may be coincidence.

If I submit the shelved changelist on the command line, it does complete.  The review is closed properly, and it shows that the submitted changelist is associated with the review.  The submit has to rename the changelist to a number after the swarm-created pending changelist.  Is that expected?

I do notice, however, that the Swarm-created pending changelists still exist.  Is that to be expected?  Do they eventually get deleted by Swarm?

The Swarm docs do not give a detailed example of a user performing a pre-commit review with the appropriate command line commands, which would be helpful.

Jeff

#2 P4Geoff

P4Geoff

    Advanced Member

  • Members
  • PipPipPip
  • 217 posts

Posted 03 July 2013 - 08:30 PM

View Postjefftharris, on 03 July 2013 - 07:53 PM, said:

I see the shelved change and also one created by Swarm for the review (I guess).  Is this normal?  Doing a p4 describe on the changelist, I see the same description but no affected files.

The existence of the new change is by design. It should have the same shelved files on it as you used to create/update the review though not be empty. Did you pass -S to describe to instruct it to list shelved files?

For each review in Swarm there is a changelist with the same id as the review which is managed by Swarm.
So to get the most recent proposed work for pre-commit review 1234 I simply unshelve change 1234.

Having a 'change of authority' for the review that has a known id makes it simpler to iterate on work. Particularly if more than one person is contributing or you switch computers. You never need to wonder which changelist id holds the most up to date shelved work.


View Postjefftharris, on 03 July 2013 - 07:53 PM, said:

However, when I click on the "Approve and commit" button, I consistently get errors indicating that there are no files to submit.  I sometimes also get another pending changelist created by Swarm.  I attribute the error to the Swarm changelist not having any affected files to submit, but that may be coincidence.

Are the files under review in a standard depot or a streams depot?

Our 2013.1 release doesn't support committing to a streams depot (2013.2 should) and you can get this rather cryptic error.
If its not a streams depot kindly advise though and I'll help you get it sorted.

View Postjefftharris, on 03 July 2013 - 07:53 PM, said:

If I submit the shelved changelist on the command line, it does complete.  The review is closed properly, and it shows that the submitted changelist is associated with the review.  The submit has to rename the changelist to a number after the swarm-created pending changelist.  Is that expected?

In Perforce, committed changelist ids always move forward; this is expected though I can understand how its slightly odd to look at in this circumstance.

View Postjefftharris, on 03 July 2013 - 07:53 PM, said:

I do notice, however, that the Swarm-created pending changelists still exist.  Is that to be expected?  Do they eventually get deleted by Swarm?

Swarm hangs onto the changelist that shares the review's id (in a pending change state) forever.

We keep it around as this allows a committed review to transition back to a pre-commit state later on if you determine it needs revisions.

View Postjefftharris, on 03 July 2013 - 07:53 PM, said:

The Swarm docs do not give a detailed example of a user performing a pre-commit review with the appropriate command line commands, which would be helpful.

Excellent suggestion; I have filled a doc job to ensure we add details on that usage.


Sorry to hear you are having some difficulties with Swarm, thanks for taking the time to report your issues.

Geoff

#3 jefftharris

jefftharris

    Member

  • Members
  • PipPip
  • 14 posts

Posted 03 July 2013 - 09:07 PM

I had not passed the -S flag to describe, only -s.  I am now seeing the shelved files for the review changelist.  As for the persistent pending changelists, we'll just know to ignore them so no problem there.

I am using a stream, so that is likely why the approve and commit is failing.  We can use the command line until 2013.2.

Will 2013.2 also support streams better for projects?  I am currently giving the stream's depot view as a path for a branch, but it would be easier to just specify a stream and have Swarm figure out the paths and even the branches for all of the stream's children.

Thanks for your help,
Jeff

#4 P4Geoff

P4Geoff

    Advanced Member

  • Members
  • PipPipPip
  • 217 posts

Posted 03 July 2013 - 09:14 PM

View Postjefftharris, on 03 July 2013 - 09:07 PM, said:

I had not passed the -S flag to describe, only -s.  I am now seeing the shelved files for the review changelist.  As for the persistent pending changelists, we'll just know to ignore them so no problem there.

Happy to hear that cleared it up.

View Postjefftharris, on 03 July 2013 - 09:07 PM, said:

Will 2013.2 also support streams better for projects?  I am currently giving the stream's depot view as a path for a branch, but it would be easier to just specify a stream and have Swarm figure out the paths and even the branches for all of the stream's children.

We dug pretty deeply into what Swarm can do to make the streams experience optimal.
For 2013.2 we'll likely just get our first phase of work in on streams, the primary improvement you'll see is the ability to commit via Swarm.

For follow on releases we are looking at having Swarm flesh out the full stream view automatically.
We're hearing mixed feedback regarding import paths so are researching more before we implement. Some customers don't want to see import path activity and some do; it also isn't clear if import path reviews should impact a stream project or not.
If you have thoughts on how you would like things to work please share, we'll take your input into account when designing things.

The idea of automatically adding streams if you just specify the mainline also occurred to us. I was a bit concerned automatically dragging in task or development streams might add too much noise but again your insights would be greatly appreciated on the topic.

Thanks for taking the time to look at Swarm and ask questions!

#5 jefftharris

jefftharris

    Member

  • Members
  • PipPip
  • 14 posts

Posted 08 July 2013 - 06:09 PM

We have a shared mainline between multiple projects, so starting all the way at the top would not work for our setup.   We have virtual streams off of the mainline to define each project, so those would be our starting point.  The automatic branch population may be overkill and, as you say, tough to get right generically.  An easy method to create a branch and simply fill in the stream or streams associated with it would be sufficient for our usage.

As for imports, I would like to see the imported changes as a part of the project.  The import is there for a reason, and so changes to its files are relevant to the project and should be visible to members of the project.

Jeff

#6 P4Geoff

P4Geoff

    Advanced Member

  • Members
  • PipPipPip
  • 217 posts

Posted 08 July 2013 - 08:05 PM

View Postjefftharris, on 08 July 2013 - 06:09 PM, said:

We have a shared mainline between multiple projects, so starting all the way at the top would not work for our setup.   We have virtual streams off of the mainline to define each project, so those would be our starting point.  The automatic branch population may be overkill and, as you say, tough to get right generically.  An easy method to create a branch and simply fill in the stream or streams associated with it would be sufficient for our usage.

As for imports, I would like to see the imported changes as a part of the project.  The import is there for a reason, and so changes to its files are relevant to the project and should be visible to members of the project.

Jeff


That's really helpful thanks for the additional insights to your usage. I'll keep it in mind as we design things.

-Geoff



Also tagged with one or more of these keywords: swarm

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users