Efficient way to identify the change sets
3 answers
Change sets are Jazz Items and are identified by their item id.
I am not sure what you mean about translating change sets to the file
system ... the file system mirror maintained by the RTC client is a
mapping between files/folders on disk and versionable states stored in a
workspace's configuration. You could do a similar thing by traversing
the configuration of each component of the the stream.
Hope this helps,
JohnC
SCM Server
vkcind wrote:
I am not sure what you mean about translating change sets to the file
system ... the file system mirror maintained by the RTC client is a
mapping between files/folders on disk and versionable states stored in a
workspace's configuration. You could do a similar thing by traversing
the configuration of each component of the the stream.
Hope this helps,
JohnC
SCM Server
vkcind wrote:
What is an efficient way to identify the change sets with respect to a
stream and then translate those change sets to file system.
Hi John,
Thanks for your reply.
I'm working on the integration of Jazz with third party SCM repository. So what I need is a efficient mechanism to identify the changes made on both the repositories since the last synchronization (like which files have been newly created or modified on Jazz repository and which files have been created or modified on the third party repository and which have been modified on both the repositories (candidates for merge)).
1. Now I manually extract the code from my repository and created a Jazz stream from it and make it available to the RTC users.
2. Then Jazz users make changes in certain files, create new files etc. and deliver the changes to the Jazz stream.
3. There are third party repository users who modify or create files in third party repository.
4. Now I'm able to figure out what are the changes done on my repository
Now I'm able to figure out the files changed on the third party repository. My problem is how identify the file changes (file modification, creation, move etc) programmatically in the Jazz repository.
Thanks
Thanks for your reply.
I'm working on the integration of Jazz with third party SCM repository. So what I need is a efficient mechanism to identify the changes made on both the repositories since the last synchronization (like which files have been newly created or modified on Jazz repository and which files have been created or modified on the third party repository and which have been modified on both the repositories (candidates for merge)).
1. Now I manually extract the code from my repository and created a Jazz stream from it and make it available to the RTC users.
2. Then Jazz users make changes in certain files, create new files etc. and deliver the changes to the Jazz stream.
3. There are third party repository users who modify or create files in third party repository.
4. Now I'm able to figure out what are the changes done on my repository
Now I'm able to figure out the files changed on the third party repository. My problem is how identify the file changes (file modification, creation, move etc) programmatically in the Jazz repository.
Thanks
Change sets are Jazz Items and are identified by their item id.
I am not sure what you mean about translating change sets to the file
system ... the file system mirror maintained by the RTC client is a
mapping between files/folders on disk and versionable states stored in a
workspace's configuration. You could do a similar thing by traversing
the configuration of each component of the the stream.
Hope this helps,
JohnC
SCM Server
vkcind wrote:
What is an efficient way to identify the change sets with respect to a
stream and then translate those change sets to file system.
The problem here is that Jazz changes are not path based. Therefore, it
is hard to map a set of changes that are identified by paths to a set
changes that are identified by ids. Further complicating this is the
fact that Jazz (and possibly your third party SCM) track moves. We have
been doing some investigation into this (and have had working prototypes
in the past) and the easiest way to manage this was to have a workspace
in Jazz that mirrors the state of your third party repository. The
advantage of this is that you can easily accept the changes from your
third party SCM since the paths in your mirror workspace match the paths
in your other repo. The sync process would then look something like this:
1) Accept all changes from repo X into the mirror Jazz workspace.
2) Accept all these changes into your Stream workspace resolving any
conflicts that occur.
3) Deliver the Jazz changes to your other repo and your mirror workspace
which should now be possible since the mirror and the third party repo
are identical and have the same paths etc.
Of course, this is a simplification and there are some complications
that would need to be dealt with.
As for you original question, the above is one way to get the paths of
the changed files in Jazz (i.e. have a workspace that contains them). In
the original syncing prototype that was used when the project started
o sync Jazz changes with CVS, the paths were calculated using the class
com.ibm.team.scm.client.importz.internal.utils.PartialFileSystemView
which is available in the RTC source but is currently not used.
Michael
vkcind wrote:
is hard to map a set of changes that are identified by paths to a set
changes that are identified by ids. Further complicating this is the
fact that Jazz (and possibly your third party SCM) track moves. We have
been doing some investigation into this (and have had working prototypes
in the past) and the easiest way to manage this was to have a workspace
in Jazz that mirrors the state of your third party repository. The
advantage of this is that you can easily accept the changes from your
third party SCM since the paths in your mirror workspace match the paths
in your other repo. The sync process would then look something like this:
1) Accept all changes from repo X into the mirror Jazz workspace.
2) Accept all these changes into your Stream workspace resolving any
conflicts that occur.
3) Deliver the Jazz changes to your other repo and your mirror workspace
which should now be possible since the mirror and the third party repo
are identical and have the same paths etc.
Of course, this is a simplification and there are some complications
that would need to be dealt with.
As for you original question, the above is one way to get the paths of
the changed files in Jazz (i.e. have a workspace that contains them). In
the original syncing prototype that was used when the project started
o sync Jazz changes with CVS, the paths were calculated using the class
com.ibm.team.scm.client.importz.internal.utils.PartialFileSystemView
which is available in the RTC source but is currently not used.
Michael
vkcind wrote:
Hi John,
Thanks for your reply.
I'm working on the integration of Jazz with third party SCM
repository. So what I need is a efficient mechanism to identify the
changes made on both the repositories since the last synchronization
(like which files have been newly created or modified on Jazz
repository and which files have been created or modified on the third
party repository and which have been modified on both the repositories
(candidates for merge)).
1. Now I manually extract the code from my repository and created a
Jazz stream from it and make it available to the RTC users.
2. Then Jazz users make changes in certain files, create new files
etc. and deliver the changes to the Jazz stream.
3. There are third party repository users who modify or create files
in third party repository.
4. Now I'm able to figure out what are the changes done on my
repository
Now I'm able to figure out the files changed on the third party
repository. My problem is how identify the file changes (file
modification, creation, move etc) programmatically in the Jazz
repository.
Thanks
John Camelonwrote:
Change sets are Jazz Items and are identified by their item id.
I am not sure what you mean about translating change sets to the
file
system ... the file system mirror maintained by the RTC client is a
mapping between files/folders on disk and versionable states stored
in a
workspace's configuration. You could do a similar thing by
traversing
the configuration of each component of the the stream.
Hope this helps,
JohnC
SCM Server
vkcind wrote:
What is an efficient way to identify the change sets with respect to
a
stream and then translate those change sets to file system.