Unable to lock file D:\workspace\Jirong\.jazz5\.jazzlock
I got this error in running a newly created build.
In the build definition, Load Directory, I was using the same local directory to load the build workspace (In another post, I was asking since each workspace already has a local load folder, why do we need a Load Directory here in the build definition).
The funny thing is if I change the Load directory to somewhere else other than the workspace`s local Load directory, then I am fine.
Can someone give me a good explanation
1. why do we need this Load Directory in the build definition, if I have a build workspace already has its own load folder,
2. and why I am getting this error.
3. what`s files in \.jazz5\
Thanks
Jirong
2011-07-21 13:37:40 running on host: rdz
2011-07-21 13:37:40 Should build occur?
2011-07-21 13:37:40 Yes: Always build a user initiated request.
2011-07-21 13:37:40 Invoking pre-build participant "com.ibm.team.build.jazzscm"
2011-07-21 13:37:41 Accepting changes into workspace "Simple Integration Stream Build Workspace" ...
com.ibm.team.filesystem.client.CopyFileAreaLockedByOtherProcess: Status INFO: com.ibm.team.filesystem.client code=0 Unable to lock file D:\workspace\Jirong\.jazz5\.jazzlock null
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.ensureExclusiveCFAAccess(SharingMetadata2.java:3074)
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.<init>(SharingMetadata2.java:1636)
at com.ibm.team.filesystem.client.internal.core.SharingMetadataFactory.getSharingMetadata(SharingMetadataFactory.java:42)
at
In the build definition, Load Directory, I was using the same local directory to load the build workspace (In another post, I was asking since each workspace already has a local load folder, why do we need a Load Directory here in the build definition).
The funny thing is if I change the Load directory to somewhere else other than the workspace`s local Load directory, then I am fine.
Can someone give me a good explanation
1. why do we need this Load Directory in the build definition, if I have a build workspace already has its own load folder,
2. and why I am getting this error.
3. what`s files in \.jazz5\
Thanks
Jirong
2011-07-21 13:37:40 running on host: rdz
2011-07-21 13:37:40 Should build occur?
2011-07-21 13:37:40 Yes: Always build a user initiated request.
2011-07-21 13:37:40 Invoking pre-build participant "com.ibm.team.build.jazzscm"
2011-07-21 13:37:41 Accepting changes into workspace "Simple Integration Stream Build Workspace" ...
com.ibm.team.filesystem.client.CopyFileAreaLockedByOtherProcess: Status INFO: com.ibm.team.filesystem.client code=0 Unable to lock file D:\workspace\Jirong\.jazz5\.jazzlock null
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.ensureExclusiveCFAAccess(SharingMetadata2.java:3074)
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.<init>(SharingMetadata2.java:1636)
at com.ibm.team.filesystem.client.internal.core.SharingMetadataFactory.getSharingMetadata(SharingMetadataFactory.java:42)
at
5 answers
I'm not sure what you mean by "a build workspace already has its own
load folder". The place where a given build definition loads a given
repository workspace is specified in the Load Directory of that build
definition.
Cheers,
Geoff
On 7/21/2011 2:38 PM, hujirong wrote:
load folder". The place where a given build definition loads a given
repository workspace is specified in the Load Directory of that build
definition.
Cheers,
Geoff
On 7/21/2011 2:38 PM, hujirong wrote:
I got this error in running a newly created build.
In the build definition, Load Directory, I was using the same local
directory to load the build workspace (In another post, I was asking
since each workspace already has a local load folder, why do we need
a Load Directory here in the build definition).
The funny thing is if I change the Load directory to somewhere else
other than the workspace`s local Load directory, then I am fine.
Can someone give me a good explanation
1. why do we need this Load Directory in the build definition, if I
have a build workspace already has its own load folder,
2. and why I am getting this error.
3. what`s files in \.jazz5\
Thanks
Jirong
2011-07-21 13:37:40 running on host: rdz
2011-07-21 13:37:40 Should build occur?
2011-07-21 13:37:40 Yes: Always build a user
initiated request.
2011-07-21 13:37:40 Invoking pre-build participant
"com.ibm.team.build.jazzscm"
2011-07-21 13:37:41 Accepting changes into
workspace "Simple Integration Stream Build Workspace" ...
com.ibm.team.filesystem.client.CopyFileAreaLockedByOtherProcess:
Status INFO: com.ibm.team.filesystem.client code=0 Unable to lock
file D:\workspace\Jirong\.jazz5\.jazzlock null
at
com.ibm.team.filesystem.client.internal.core.SharingMetadata2.ensureExclusiveCFAAccess(SharingMetadata2.java:3074)
at
com.ibm.team.filesystem.client.internal.core.SharingMetadata2.<init>(SharingMetadata2.java:1636)
at
com.ibm.team.filesystem.client.internal.core.SharingMetadataFactory.getSharingMetadata(SharingMetadataFactory.java:42)
at
After I create a new workspace, I right-click, choose Load, from there in the Advanced Option, I specify a local folder to load the workspace contents. I do this because I want to see the projects and files or add a new build script. This folder is what I am referring as workspace`s own local folder.
Then if this happens to be a build workspace, and I have to give another one in Load Directory. I believe this is why I am getting the error.
So I am wrong somewhere. Please help.
Thanks again.
Jirong
Then if this happens to be a build workspace, and I have to give another one in Load Directory. I believe this is why I am getting the error.
So I am wrong somewhere. Please help.
Thanks again.
Jirong
I'm not sure what you mean by "a build workspace already has its own
load folder". The place where a given build definition loads a given
repository workspace is specified in the Load Directory of that build
definition.
Cheers,
Geoff
One key point is that a sandbox (which is what contains the loaded files
on disk) knows what repository workspace it was loaded from, but a
repository workspace has no idea which (if any) sandboxes have been
loaded from that workspace.
Another key point is that although a workspace should be loaded into at
most one sandbox to do real work (like checking in files), you can have
as many "read-only" sandboxes as you want associated with a single
repository workspace. In fact, this is exactly what happens when you
request a "personal build" using your normal development workspace. On
the machine where the JBE for your personal build is running, it will
load a sandbox from your development workspace, and then do all its
build operations there. Since it doesn't checkin any changes from that
sandbox, this doesn't interfere with your normal development activity
using your sandbox for that repository workspace.
Similarly, for team builds, every concurrent build loads its own sandbox
for the workspace specified in the build definition.
So in summary, when it comes to "build", there commonly are multiple
sandboxes that load a given repository workspace (i.e., on every machine
where a JBE executes a build definition for that repository workspace).
Cheers,
Geoff
On 7/21/2011 3:08 PM, hujirong wrote:
on disk) knows what repository workspace it was loaded from, but a
repository workspace has no idea which (if any) sandboxes have been
loaded from that workspace.
Another key point is that although a workspace should be loaded into at
most one sandbox to do real work (like checking in files), you can have
as many "read-only" sandboxes as you want associated with a single
repository workspace. In fact, this is exactly what happens when you
request a "personal build" using your normal development workspace. On
the machine where the JBE for your personal build is running, it will
load a sandbox from your development workspace, and then do all its
build operations there. Since it doesn't checkin any changes from that
sandbox, this doesn't interfere with your normal development activity
using your sandbox for that repository workspace.
Similarly, for team builds, every concurrent build loads its own sandbox
for the workspace specified in the build definition.
So in summary, when it comes to "build", there commonly are multiple
sandboxes that load a given repository workspace (i.e., on every machine
where a JBE executes a build definition for that repository workspace).
Cheers,
Geoff
On 7/21/2011 3:08 PM, hujirong wrote:
After I create a new workspace, I right-click, choose Load, from there
in the Advanced Option, I specify a local folder to load the workspace
contents. I do this because I want to see the projects and files or
add a new build script. This folder is what I am referring as
workspace`s own local folder.
Then if this happens to be a build workspace, and I have to give
another one in Load Directory. I believe this is why I am getting the
error.
So I am wrong somewhere. Please help.
Thanks again.
Jirong
gmclemmwrote:
I'm not sure what you mean by "a build workspace already has its
own
load folder". The place where a given build definition loads
a given
repository workspace is specified in the Load Directory of that
build
definition.
Cheers,
Geoff
OK, now I get it.
Let's for a typical development stream shared by a few developers, let's say we have a team workspace flow targeting to this stream and each developer also has his own workspace (shall flow targeting to the team workspace or steam? or we can share the team workspace?).
Each developer creates his own sandbox during the Load operation (specify the local directory in Advanced Option), an incremental build created its own sandbox by specifying the local folder in the Load Directory, and the nightly build also created its own sandbox by specifying the local folder in the Load Directory. This is why there is a Load Directory. The intention is not to share the sandbox with development activity.
Thanks for your help.
Jirong
Let's for a typical development stream shared by a few developers, let's say we have a team workspace flow targeting to this stream and each developer also has his own workspace (shall flow targeting to the team workspace or steam? or we can share the team workspace?).
Each developer creates his own sandbox during the Load operation (specify the local directory in Advanced Option), an incremental build created its own sandbox by specifying the local folder in the Load Directory, and the nightly build also created its own sandbox by specifying the local folder in the Load Directory. This is why there is a Load Directory. The intention is not to share the sandbox with development activity.
Thanks for your help.
Jirong
Yes, I do believe that you've got it (:-).
Note: I'd call it a "build workspace" rather than a "team workspace" (to
make sure nobody is confused into thinking they can/should do
development in that workspace).
All of the workspaces (both developer workspaces and build workspaces)
would have the team stream as their flow target.
Cheers,
Geoff
On 7/22/2011 10:53 AM, hujirong wrote:
Note: I'd call it a "build workspace" rather than a "team workspace" (to
make sure nobody is confused into thinking they can/should do
development in that workspace).
All of the workspaces (both developer workspaces and build workspaces)
would have the team stream as their flow target.
Cheers,
Geoff
On 7/22/2011 10:53 AM, hujirong wrote:
OK, now I get it.
Let's for a typical development stream shared by a few developers,
let's say we have a team workspace flow targeting to this stream and
each developer also has his own workspace (shall flow targeting to
the team workspace or steam? or we can share the team workspace?).
Each developer creates his own sandbox during the Load operation
(specify the local directory in Advanced Option), an incremental
build created its own sandbox by specifying the local folder in the
Load Directory, and the nightly build also created its own sandbox
by specifying the local folder in the Load Directory. This is why
there is a Load Directory. The intention is not to share the sandbox
with development activity.
Thanks for your help.
Jirong