Home » Eclipse Projects » Mylyn » Dealing with same file in two separate change sets
| Dealing with same file in two separate change sets [message #65937] |
Wed, 04 March 2009 00:31  |
 Scott Kovatch
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Hi,
I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
bugzilla system. What is the expected workflow when you have changes
for multiple bugs in the same file?
For example, let's say I work on bug #1, and make some changes to
A.java, B.java and C.java. I make some progress, but get stuck, so I
move on to bug #2. That bug requires also requires changes to D.java
and also A.java.
What steps do I take so the changes for A.java in bug #2 can be
segregated from the changes for bug #1? The user guide leads me to
believe Mylyn can only handle changes at the file level, so I'm not
sure how I would go about keeping track of the changes without
collisions.
Is that what Attach Context is for?
I'm just getting started with Mylyn, so I may just be missing a common
use case here.
Thanks,
Scott K.
|
|
|
| Re: Dealing with same file in two separate change sets [message #65960 is a reply to message #65937] |
Wed, 04 March 2009 12:38  |
Jörg Thönnes
Messages: 229
Registered: July 2009 |
Senior Member |
|
|
Hi Scott,
On 03/04/09 01:31, Scott Kovatch wrote:
> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
> bugzilla system. What is the expected workflow when you have changes for
> multiple bugs in the same file?
Normally, I would solve them step by step. If you have changes for several bugs in one file, this is
difficult to sort out.
> For example, let's say I work on bug #1, and make some changes to
> A.java, B.java and C.java. I make some progress, but get stuck, so I
> move on to bug #2.
I guess you cannot commit the changes made for bug #1 since they are not complete.
I suggest to save your state somehow and revert the changes made for bug #2 before going forward to
bug #2
> That bug requires also requires changes to D.java and
> also A.java.
> What steps do I take so the changes for A.java in bug #2 can be
> segregated from the changes for bug #1? The user guide leads me to
> believe Mylyn can only handle changes at the file level, so I'm not sure
> how I would go about keeping track of the changes without collisions.
Mylyn tracks the files and java elements your are currently working on. In addition, builds on the
team provider (here CVS) facility to manage change sets.
But since CVS does not understand changes to single java elements, Mylyn can do nothing here.
> Is that what Attach Context is for?
No, it just attaches your current Mylyn context (i.e. the collection of files and java elements etc.
you have in focus) to the repository task. So other people could pick up this context and continue
working were you left off -- in terms of contexts, not changes made.
Typical usage in Mylyn related bug reports:
1. somebody looks at the bug and attaches a context established during analysis
2. somebody solves the issue and attaches the final context on resolving/closing
In this way, you can easily communicate something like: look at this package, this file, this method
etc.
> I'm just getting started with Mylyn, so I may just be missing a common
> use case here.
Your use case is very common, actually I had this case yesterday evening.
I solved it this way:
1. create a patch diff of the changes made for bug #1
2. save the patch somewhere, e.g. as attachment to the bug #1 task
3. revert changes
4. start working with bug #2
5. resolve and commit bug #2
6. start working with bug #1 by applying patch from bug #1
7. resolve and commit bug #2
Much more elegantly (but more heavy-weight) you solve this issue using a branch in your version
control system:
1. Create development branch for bug #1
2. Switch to branch #1
3. Do some changes
4. Move to bug #2
5. Create dev branch bug #2
6. Resolve bug #2
7. Merge dev branch #2 to trunk
8. Move to bug #1 and dev branch #1
9. Resolve bug #2
10. Merge dev branch #1 to trunk
Mylyn helps you to track your current context and keep it separated for different task. And it
provides you with a comment templates and creates CVS change sets for you.
But if a file is part of different bugs and Mylyn context, it will appear in different change sets
in the Team Synchronize view. Then you can manually move the file to a different or no change set.
Here is also one special case to take care:
If you delete a file during the work on a bug, you want this file to be part of the CVS change set
since the deletion shall be checked in as part of this bug (change set comment). But Mylyn regards a
file deletion as complete lost of interest, ie it removes the file from the context and as a
consequence from the CVS change set. In that special case, you have to add it manually to the change
set.
Hope this helps in the first place.
Please have a look at the FAQs and the wonderful articles on IBM Developerworks and on the screen
cast posted my Mik Kersten.
Cheers, Jörg
|
|
|
| Re: Dealing with same file in two separate change sets [message #65980 is a reply to message #65960] |
Wed, 04 March 2009 14:18 |
Randall Becker
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Hi Scott,
I have a slightly different approach to solving this. It's a
function/space tradeoff.
Jörg Thönnes wrote:
> On 03/04/09 01:31, Scott Kovatch wrote:
>> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
>> bugzilla system. What is the expected workflow when you have changes for
>> multiple bugs in the same file?
> Normally, I would solve them step by step. If you have changes for
> several bugs in one file, this is difficult to sort out.
>> For example, let's say I work on bug #1, and make some changes to
>> A.java, B.java and C.java. I make some progress, but get stuck, so I
>> move on to bug #2.
What you can do is set up multiple workspaces on your machine - presumably
you have a "main" workspace you use on a regular basis, say W0. Import all
relevant projects to the each alternate workspace, say W1 and W2. You can
work on bug 1 in W1 and bug 2 in W2. If you get stuck on bug 1 and need to
think on it, switch to W2 and work on it. Mylyn will keep the contexts
separate for each workspace (it's under .metadata in each workspace). Once
you're happy with the changes for bug 2, for example, check those in from
W2 and update W0. Then, when bug 1 is ready, you should update W2 with the
changes and merge them (that's where the Synchronize view is useful). When
you've merged the changes, check those cumulative changes in, and update
W0. You can then discard W1 or W2 at your leasure.
The approach is similar to two developers working on the problem. You've
simulated cloning yourself in this case, so just keep yourself straight as
far as what you're doing in each workspace. It's not a perfect solution,
takes a lot more disk (for the additional workspace), but it does work
successfully for us when we're prototyping a new concept and having to
also support ongoing enhancements.
Cheers,
Randall
|
|
|
| Re: Dealing with same file in two separate change sets [message #66000 is a reply to message #65980] |
Wed, 04 March 2009 14:27 |
Jonathan Gossage
Messages: 42
Registered: July 2009 |
Member |
|
|
Randall Becker wrote:
> Hi Scott,
>
> I have a slightly different approach to solving this. It's a
> function/space tradeoff.
>
> Jörg Thönnes wrote:
>> On 03/04/09 01:31, Scott Kovatch wrote:
>>> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
>>> bugzilla system. What is the expected workflow when you have changes for
>>> multiple bugs in the same file?
>
>> Normally, I would solve them step by step. If you have changes for
>> several bugs in one file, this is difficult to sort out.
>
>>> For example, let's say I work on bug #1, and make some changes to
>>> A.java, B.java and C.java. I make some progress, but get stuck, so I
>>> move on to bug #2.
>
> What you can do is set up multiple workspaces on your machine -
> presumably you have a "main" workspace you use on a regular basis, say
> W0. Import all relevant projects to the each alternate workspace, say W1
> and W2. You can work on bug 1 in W1 and bug 2 in W2. If you get stuck on
> bug 1 and need to think on it, switch to W2 and work on it. Mylyn will
> keep the contexts separate for each workspace (it's under .metadata in
> each workspace). Once you're happy with the changes for bug 2, for
> example, check those in from W2 and update W0. Then, when bug 1 is
> ready, you should update W2 with the changes and merge them (that's
> where the Synchronize view is useful). When you've merged the changes,
> check those cumulative changes in, and update W0. You can then discard
> W1 or W2 at your leasure.
>
> The approach is similar to two developers working on the problem. You've
> simulated cloning yourself in this case, so just keep yourself straight
> as far as what you're doing in each workspace. It's not a perfect
> solution, takes a lot more disk (for the additional workspace), but it
> does work successfully for us when we're prototyping a new concept and
> having to also support ongoing enhancements.
>
> Cheers,
>
Another possibility, if you have access to a source control system that
permits user created branches is to create a branch for each bug and
merge each bug back to the master when it is complete. Typically this
approach results in a lower incidence of manual finger problems than
other approaches.
Jonathan Gossage
> Randall
>
|
|
|
| Re: Dealing with same file in two separate change sets [message #66022 is a reply to message #65980] |
Wed, 04 March 2009 19:23 |
Scott Kovatch
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
On 3/4/09 6:18 AM, in article
cce6251509d10ac350f5fb99056af0f8$1@www.eclipse.org, "Randall Becker"
<rsbecker@nexbridge.com> wrote:
> Jörg Thönnes wrote:
>> On 03/04/09 01:31, Scott Kovatch wrote:
>>> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
>>> bugzilla system. What is the expected workflow when you have changes for
>>> multiple bugs in the same file?
>
>> Normally, I would solve them step by step. If you have changes for
>> several bugs in one file, this is difficult to sort out.
>
>>> For example, let's say I work on bug #1, and make some changes to
>>> A.java, B.java and C.java. I make some progress, but get stuck, so I
>>> move on to bug #2.
>
> What you can do is set up multiple workspaces on your machine - presumably
> you have a "main" workspace you use on a regular basis, say W0. Import all
> relevant projects to the each alternate workspace, say W1 and W2. You can
> work on bug 1 in W1 and bug 2 in W2. If you get stuck on bug 1 and need to
> think on it, switch to W2 and work on it. Mylyn will keep the contexts
> separate for each workspace (it's under .metadata in each workspace). Once
> you're happy with the changes for bug 2, for example, check those in from
> W2 and update W0. Then, when bug 1 is ready, you should update W2 with the
> changes and merge them (that's where the Synchronize view is useful). When
> you've merged the changes, check those cumulative changes in, and update
> W0. You can then discard W1 or W2 at your leasure.
After having some time to sleep on it, I came up with pretty much the same
idea. In fact, I forgot that this is how I've solved the problem in the past
in this situation, without Eclipse or Mylyn. You also already answered the
follow up that came to mind, in that the Mylyn data is stored per-workspace,
so the task contexts won't overwrite each other.
I'm already a heavy user of the Synchronize view, and I like how the CVS
support in Mylyn shows me exactly what changes came from other developers.
> The approach is similar to two developers working on the problem. You've
> simulated cloning yourself in this case, so just keep yourself straight as
> far as what you're doing in each workspace. It's not a perfect solution,
> takes a lot more disk (for the additional workspace), but it does work
> successfully for us when we're prototyping a new concept and having to
> also support ongoing enhancements.
Fortunately for me the disk overhead won't be that bad. I'm working on the
SWT, which doesn't take up an unreasonable amount of disk space per
workspace.
Thanks for the responses, everyone. Randall's suggestion is the right level
of overhead that I need for my situation, and I should be able to add Mylyn
without problems.
-- Scott
---------------
Scott Kovatch
Flex Engineering
Adobe Systems, Inc.
skovatch@adobe.com
I am Scott Kovatch, and I approved this message.
|
|
|
| Re: Dealing with same file in two separate change sets [message #66085 is a reply to message #65937] |
Thu, 05 March 2009 14:30 |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 3/3/2009 7:31 PM, Scott Kovatch wrote:
> Hi,
>
> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
> bugzilla system. What is the expected workflow when you have changes for
> multiple bugs in the same file?
>
> For example, let's say I work on bug #1, and make some changes to
> A.java, B.java and C.java. I make some progress, but get stuck, so I
> move on to bug #2. That bug requires also requires changes to D.java and
> also A.java.
>
> What steps do I take so the changes for A.java in bug #2 can be
> segregated from the changes for bug #1? The user guide leads me to
> believe Mylyn can only handle changes at the file level, so I'm not sure
> how I would go about keeping track of the changes without collisions.
>
> Is that what Attach Context is for?
>
> I'm just getting started with Mylyn, so I may just be missing a common
> use case here.
I recently brought up a suggestion for support of this. See this
discussion and the related bug report:
http://dev.eclipse.org/newslists/news.eclipse.tools.mylyn/ms g01592.html
https://bugs.eclipse.org/bugs/show_bug.cgi?id=263641
Your comments and ideas are welcomed in the bug report; I'd like to move
it along and I think more interest/participation will help with that.
Eric
|
|
|
| Re: Dealing with same file in two separate change sets [message #596465 is a reply to message #65937] |
Wed, 04 March 2009 12:38 |
Jörg Thönnes
Messages: 229
Registered: July 2009 |
Senior Member |
|
|
Hi Scott,
On 03/04/09 01:31, Scott Kovatch wrote:
> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
> bugzilla system. What is the expected workflow when you have changes for
> multiple bugs in the same file?
Normally, I would solve them step by step. If you have changes for several bugs in one file, this is
difficult to sort out.
> For example, let's say I work on bug #1, and make some changes to
> A.java, B.java and C.java. I make some progress, but get stuck, so I
> move on to bug #2.
I guess you cannot commit the changes made for bug #1 since they are not complete.
I suggest to save your state somehow and revert the changes made for bug #2 before going forward to
bug #2
> That bug requires also requires changes to D.java and
> also A.java.
> What steps do I take so the changes for A.java in bug #2 can be
> segregated from the changes for bug #1? The user guide leads me to
> believe Mylyn can only handle changes at the file level, so I'm not sure
> how I would go about keeping track of the changes without collisions.
Mylyn tracks the files and java elements your are currently working on. In addition, builds on the
team provider (here CVS) facility to manage change sets.
But since CVS does not understand changes to single java elements, Mylyn can do nothing here.
> Is that what Attach Context is for?
No, it just attaches your current Mylyn context (i.e. the collection of files and java elements etc.
you have in focus) to the repository task. So other people could pick up this context and continue
working were you left off -- in terms of contexts, not changes made.
Typical usage in Mylyn related bug reports:
1. somebody looks at the bug and attaches a context established during analysis
2. somebody solves the issue and attaches the final context on resolving/closing
In this way, you can easily communicate something like: look at this package, this file, this method
etc.
> I'm just getting started with Mylyn, so I may just be missing a common
> use case here.
Your use case is very common, actually I had this case yesterday evening.
I solved it this way:
1. create a patch diff of the changes made for bug #1
2. save the patch somewhere, e.g. as attachment to the bug #1 task
3. revert changes
4. start working with bug #2
5. resolve and commit bug #2
6. start working with bug #1 by applying patch from bug #1
7. resolve and commit bug #2
Much more elegantly (but more heavy-weight) you solve this issue using a branch in your version
control system:
1. Create development branch for bug #1
2. Switch to branch #1
3. Do some changes
4. Move to bug #2
5. Create dev branch bug #2
6. Resolve bug #2
7. Merge dev branch #2 to trunk
8. Move to bug #1 and dev branch #1
9. Resolve bug #2
10. Merge dev branch #1 to trunk
Mylyn helps you to track your current context and keep it separated for different task. And it
provides you with a comment templates and creates CVS change sets for you.
But if a file is part of different bugs and Mylyn context, it will appear in different change sets
in the Team Synchronize view. Then you can manually move the file to a different or no change set.
Here is also one special case to take care:
If you delete a file during the work on a bug, you want this file to be part of the CVS change set
since the deletion shall be checked in as part of this bug (change set comment). But Mylyn regards a
file deletion as complete lost of interest, ie it removes the file from the context and as a
consequence from the CVS change set. In that special case, you have to add it manually to the change
set.
Hope this helps in the first place.
Please have a look at the FAQs and the wonderful articles on IBM Developerworks and on the screen
cast posted my Mik Kersten.
Cheers, Jörg
|
|
|
| Re: Dealing with same file in two separate change sets [message #596473 is a reply to message #65960] |
Wed, 04 March 2009 14:18 |
Randall Becker
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Hi Scott,
I have a slightly different approach to solving this. It's a
function/space tradeoff.
Jörg Thönnes wrote:
> On 03/04/09 01:31, Scott Kovatch wrote:
>> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
>> bugzilla system. What is the expected workflow when you have changes for
>> multiple bugs in the same file?
> Normally, I would solve them step by step. If you have changes for
> several bugs in one file, this is difficult to sort out.
>> For example, let's say I work on bug #1, and make some changes to
>> A.java, B.java and C.java. I make some progress, but get stuck, so I
>> move on to bug #2.
What you can do is set up multiple workspaces on your machine - presumably
you have a "main" workspace you use on a regular basis, say W0. Import all
relevant projects to the each alternate workspace, say W1 and W2. You can
work on bug 1 in W1 and bug 2 in W2. If you get stuck on bug 1 and need to
think on it, switch to W2 and work on it. Mylyn will keep the contexts
separate for each workspace (it's under .metadata in each workspace). Once
you're happy with the changes for bug 2, for example, check those in from
W2 and update W0. Then, when bug 1 is ready, you should update W2 with the
changes and merge them (that's where the Synchronize view is useful). When
you've merged the changes, check those cumulative changes in, and update
W0. You can then discard W1 or W2 at your leasure.
The approach is similar to two developers working on the problem. You've
simulated cloning yourself in this case, so just keep yourself straight as
far as what you're doing in each workspace. It's not a perfect solution,
takes a lot more disk (for the additional workspace), but it does work
successfully for us when we're prototyping a new concept and having to
also support ongoing enhancements.
Cheers,
Randall
|
|
|
| Re: Dealing with same file in two separate change sets [message #596480 is a reply to message #65980] |
Wed, 04 March 2009 14:27 |
Jonathan Gossage
Messages: 42
Registered: July 2009 |
Member |
|
|
Randall Becker wrote:
> Hi Scott,
>
> I have a slightly different approach to solving this. It's a
> function/space tradeoff.
>
> Jörg Thönnes wrote:
>> On 03/04/09 01:31, Scott Kovatch wrote:
>>> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
>>> bugzilla system. What is the expected workflow when you have changes for
>>> multiple bugs in the same file?
>
>> Normally, I would solve them step by step. If you have changes for
>> several bugs in one file, this is difficult to sort out.
>
>>> For example, let's say I work on bug #1, and make some changes to
>>> A.java, B.java and C.java. I make some progress, but get stuck, so I
>>> move on to bug #2.
>
> What you can do is set up multiple workspaces on your machine -
> presumably you have a "main" workspace you use on a regular basis, say
> W0. Import all relevant projects to the each alternate workspace, say W1
> and W2. You can work on bug 1 in W1 and bug 2 in W2. If you get stuck on
> bug 1 and need to think on it, switch to W2 and work on it. Mylyn will
> keep the contexts separate for each workspace (it's under .metadata in
> each workspace). Once you're happy with the changes for bug 2, for
> example, check those in from W2 and update W0. Then, when bug 1 is
> ready, you should update W2 with the changes and merge them (that's
> where the Synchronize view is useful). When you've merged the changes,
> check those cumulative changes in, and update W0. You can then discard
> W1 or W2 at your leasure.
>
> The approach is similar to two developers working on the problem. You've
> simulated cloning yourself in this case, so just keep yourself straight
> as far as what you're doing in each workspace. It's not a perfect
> solution, takes a lot more disk (for the additional workspace), but it
> does work successfully for us when we're prototyping a new concept and
> having to also support ongoing enhancements.
>
> Cheers,
>
Another possibility, if you have access to a source control system that
permits user created branches is to create a branch for each bug and
merge each bug back to the master when it is complete. Typically this
approach results in a lower incidence of manual finger problems than
other approaches.
Jonathan Gossage
> Randall
>
|
|
|
| Re: Dealing with same file in two separate change sets [message #596488 is a reply to message #65980] |
Wed, 04 March 2009 19:23 |
Scott Kovatch
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
On 3/4/09 6:18 AM, in article
cce6251509d10ac350f5fb99056af0f8$1@www.eclipse.org, "Randall Becker"
<rsbecker@nexbridge.com> wrote:
> Jörg Thönnes wrote:
>> On 03/04/09 01:31, Scott Kovatch wrote:
>>> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
>>> bugzilla system. What is the expected workflow when you have changes for
>>> multiple bugs in the same file?
>
>> Normally, I would solve them step by step. If you have changes for
>> several bugs in one file, this is difficult to sort out.
>
>>> For example, let's say I work on bug #1, and make some changes to
>>> A.java, B.java and C.java. I make some progress, but get stuck, so I
>>> move on to bug #2.
>
> What you can do is set up multiple workspaces on your machine - presumably
> you have a "main" workspace you use on a regular basis, say W0. Import all
> relevant projects to the each alternate workspace, say W1 and W2. You can
> work on bug 1 in W1 and bug 2 in W2. If you get stuck on bug 1 and need to
> think on it, switch to W2 and work on it. Mylyn will keep the contexts
> separate for each workspace (it's under .metadata in each workspace). Once
> you're happy with the changes for bug 2, for example, check those in from
> W2 and update W0. Then, when bug 1 is ready, you should update W2 with the
> changes and merge them (that's where the Synchronize view is useful). When
> you've merged the changes, check those cumulative changes in, and update
> W0. You can then discard W1 or W2 at your leasure.
After having some time to sleep on it, I came up with pretty much the same
idea. In fact, I forgot that this is how I've solved the problem in the past
in this situation, without Eclipse or Mylyn. You also already answered the
follow up that came to mind, in that the Mylyn data is stored per-workspace,
so the task contexts won't overwrite each other.
I'm already a heavy user of the Synchronize view, and I like how the CVS
support in Mylyn shows me exactly what changes came from other developers.
> The approach is similar to two developers working on the problem. You've
> simulated cloning yourself in this case, so just keep yourself straight as
> far as what you're doing in each workspace. It's not a perfect solution,
> takes a lot more disk (for the additional workspace), but it does work
> successfully for us when we're prototyping a new concept and having to
> also support ongoing enhancements.
Fortunately for me the disk overhead won't be that bad. I'm working on the
SWT, which doesn't take up an unreasonable amount of disk space per
workspace.
Thanks for the responses, everyone. Randall's suggestion is the right level
of overhead that I need for my situation, and I should be able to add Mylyn
without problems.
-- Scott
---------------
Scott Kovatch
Flex Engineering
Adobe Systems, Inc.
skovatch@adobe.com
I am Scott Kovatch, and I approved this message.
|
|
|
| Re: Dealing with same file in two separate change sets [message #596509 is a reply to message #65937] |
Thu, 05 March 2009 14:30 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
On 3/3/2009 7:31 PM, Scott Kovatch wrote:
> Hi,
>
> I'm trying to use Mylyn to manage my assigned bugs in the Eclipse
> bugzilla system. What is the expected workflow when you have changes for
> multiple bugs in the same file?
>
> For example, let's say I work on bug #1, and make some changes to
> A.java, B.java and C.java. I make some progress, but get stuck, so I
> move on to bug #2. That bug requires also requires changes to D.java and
> also A.java.
>
> What steps do I take so the changes for A.java in bug #2 can be
> segregated from the changes for bug #1? The user guide leads me to
> believe Mylyn can only handle changes at the file level, so I'm not sure
> how I would go about keeping track of the changes without collisions.
>
> Is that what Attach Context is for?
>
> I'm just getting started with Mylyn, so I may just be missing a common
> use case here.
I recently brought up a suggestion for support of this. See this
discussion and the related bug report:
http://dev.eclipse.org/newslists/news.eclipse.tools.mylyn/ms g01592.html
https://bugs.eclipse.org/bugs/show_bug.cgi?id=263641
Your comments and ideas are welcomed in the bug report; I'd like to move
it along and I think more interest/participation will help with that.
Eric
|
|
|
Goto Forum:
Current Time: Sat Nov 09 05:00:39 GMT 2024
Powered by FUDForum. Page generated in 0.05563 seconds |
] 
Search
Help
Register
Login
Home
