The point of a personal build is to build exactly the files that are in the
repository workspace you specify. It would make no sense to Accept into that
workspace.

The personal build use case is this:

You are working on some changes in eclipse.
Check them into a change set (or they already will be in a change set if you
use auto-checkin).
At this point, the changes are in your repository workspace on the server,
but not yet shared with anyone else.
You would like to perform a build to make sure things are ok before you
deliver the change set anywhere.
Request a personal build and select your repository workspace.
The build gets the exact files that are in your repository workspace.

Why would you want to have any accept occuring in this use case? If you
accepted, the whole point of "building only what's in your repository
workspace" is lost.

---
Ryan Manwiller
Jazz Team

First off, I agree the documentation on personal builds should be
improved so that these kinds of questions do not arise.

I'd suggest thinking about a "regular" build that is Jazz-SCM enabled as
"build a stream", while a personal build as "build a workspace". If you
want to build the current contents of a stream, just use a "regular"
build (no need to use a personal build).

More comments interspersed below.

ramfree17 wrote:

In that case the personal build will only be useful to me if

1) I want to build the workspace of a colleague who happened to be
unable to come into work.

Yes, that falls into the "build a workspace" category.

2) I am working only with a RTC client and I made some changes that
I cannot compile (e.g. we are using RSA 7.0.0.x and its not installed
in my current workstation).

Yes, that also falls into the "build a workspace" category.

3) I want to utilize the bandwidth and computing power of the build
engine instance.

You get the bandwidth/computing power of the build engine for either a
regular build or a personal build, so that wouldn't be a motivator to
use a personal build.

Unless I am going for #3, it is going to be much faster if I build the
contents of my own repository workspace.

Why would you think that? The files on the build machine will need to
be updated to be "current" (i.e. match what is in the stream for a
regular build, and match what is in the workspace for a workspace
build), so neither one is inherently faster than the other. It just
depends on how many changes have been made since the last build.

I see that point but can we
clarify that in the documentation? I don't think I am alone in
thinking that "I can request a personal build, the build engine
would accept the incoming changes because the tooling definition has
that enabled, but if the build fails don't notify the rest of the
team."

I agree that the team will care more about regular (stream-based) build
(because the stream is a shared resource that the whole team cares
about) than a personal build (a workspace that the workspace owner cares
about), but that is a result of what kind of build you're asking for,
not the purpose of asking for one build or another.

But I also agree that the documentation on personal builds should be
improved.

Right now I am working on sorting out the issues on the CI
implementation using the JBE. As I am doing a lot of script changes I
want to see how they will behave in a headless mode. I found out the
hard way that there are some small environment-specific
inconsistencies that can fail a build even if it seems to work fine
when I manually invoked it on my machine (i.e., the works for me
argument).

This is a separate issue, right? (I.e. not related to why personal
builds do not accept incoming changes).

Cheers,
Geoff

ramfree17 wrote:

As I am doing a lot of script changes I
want to see how they will behave in a headless mode. I found out the
hard way that there are some small environment-specific
inconsistencies that can fail a build even if it seems to work fine
when I manually invoked it on my machine (i.e., the works for me
argument).

That's the reason for personal builds. It is not always possible to
fully recreate the official build environment on your personal
development machine. You can catch most of your bugs in your IDE before
delivering, but a few bugs can only be caught by running an official
build. Personal builds allow you to test the contents of your own
repository workspace in the official build environment before you
deliver your changes.

The Repository Workspace field is initally empty when selecting Personal
Build in the Request Build dialog. Once you choose a workspace, it is
persisted, and will be populated in the field on subsequent invocations of
the dialog.

So, your team's build workspace would never be the default. You'd have to
select it.

ramfree17 wrote:

@Geoff, David:

Agreed that its a personal issue which is why I edited it out
immediately after posting it. Unfortunately it was not fast enough
although I am still confused how it still got reflected in your view
when I thought I am in a timezone ahead of most RTC developers. :)

I am guessing that Geoff and I saw the text because we read the forum
through an NNTP newsreader, not via the web. It seems that the NNTP
server doesn't deal with edited posts and continues to serve up the
original.