Bugzilla – Full Text Bug Listing
| Summary: | improve support for multiple workspaces | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Willian Mitsuda <wmitsuda> |
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ekuleshov, florian.marquardt, gabriele.garuglieri, Graham.Crowe, lothar, mik.kersten, murphy, robert.elves, simcoen, wolowicz |
| Version: | 0.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 164421 | ||
|
Description
Willian Mitsuda
I agree that the current story needs improvement. The reason that the directory is seperate is so that you can use multiple workspaces with the same directory. Note that if you do not set a custom directory, it will move automatically along with the workspace (I just updated the prefs page to indicate this). I know of at least two people using it this way, and task management best practices (e.g. David Allen's Getting Things Done) indicate that having a single place to manage your tasks is key. Also, this enables you to have your task directory checked in (although it has been ages since I worked that way myself). What I think we need to do is make sure that Mylar works well for people using two different worksapces (work and home) since this is a common mode. So a important question is, how should the task data be shared across those? Seems like import/export at the start and end of every day is way too much trouble. I am a user of the one task location, multiple workspaces. I like having the list of all my tasks available in Eclipse to know all the things I should be doing ( ;) ) even though I use separate workspaces for some of my projects. Since this is likely the less common case, the default maybe should be to make it act like a normal plug-in and in preferences have to activate the shared case? It would be good to get a sense of how most people are using it and whether home/work can be handled through a shared file system location between home and work or as part of a source repository or ... (In reply to comment #1) > I agree that the current story needs improvement. The reason that the > directory is seperate is so that you can use multiple workspaces with the same > directory. Note that if you do not set a custom directory, it will move > automatically along with the workspace (I just updated the prefs page to > indicate this). I know of at least two people using it this way, and task > management best practices (e.g. David Allen's Getting Things Done) indicate > that having a single place to manage your tasks is key. Also, this enables you > to have your task directory checked in (although it has been ages since I > worked that way myself). > What I think we need to do is make sure that Mylar works well for people using > two different worksapces (work and home) since this is a common mode. So a > important question is, how should the task data be shared across those? Seems > like import/export at the start and end of every day is way too much trouble. Hi all,
Thanks for the feedback. Let me take some points based in my own "use case":
- I use multiples workspaces to organize the multiple projects I work on.
- I also use multiple workspaces to work in different branches of the same project.
- When I release a new version of my software, I usually tag it in CVS, and make a copy of the entire workspace. The "copy" workspace is then "declared" the new development stream, and in the "original" workspace I make a branch. It is now the maintenance workspace.
- Sometimes, I also work at home, but because I only have CVS access at work, I zip the entire workspace and copy it into a flash drive. At home, I unzip it, made some changes, zip, copy to flash drive, bring to work.
At work, I don't overwrite the "original" workspace. Instead, I unzip it into a temporary location, synchronize/commit the changes, and discard this workspace. I open the "original" workspace, synchronize/update my own home changes.
So, some thoughts:
1 - I like the idea of a self-contained workspace used by Eclipse, because you known that all data related to workspace (projects, preferences, etc...) is contained inside it. This is the default behaviour. There are exceptions, of course, like linked resources, project in alternate locations, etc., but like I said, these are exceptions, for specific use cases.
The current behaviour in mylar seems to follow this same idea, but don't. The fact of assuming the {$workspace}/.mylar directory as a default data directory makes the wrong impression of it being self-contained in the workspace.
The existence of a FAQ entry about this subject is a proof of this potential misunderstanding.
2 - I'm a person who uses 5 workspaces ;-), and I can say that the tasks I work on each of them are unrelated, so there is no need to a shared repository. Eventually there is one or another task that I want to work on more than 1 workspace, but in this rare case I just open the same bug in all workspaces I use it. Even in this case, it is unlikelly that you would like to use a shared context repository, because there are different resources on each workspace.
3 - If the idea is to share the tasks contexts among the team, perhaps the task metadata should be contained inside a workspace project, or in a hidden directory for each project, etc..., like many plugins do.
(In reply to comment #1) > I agree that the current story needs improvement. The reason that the > directory is seperate is so that you can use multiple workspaces with the same > directory. I use multiple workspaces at work, in same machine ;-) Eventually, I leave 1 or 2 workspaces to work at home. So, my problem is more related to the "mobility" issue that the current behaviour can cause (I have to make the workspaces use the same name and location in every machine I bring it). > automatically along with the workspace (I just updated the prefs page to > indicate this). I know of at least two people using it this way, and task > management best practices (e.g. David Allen's Getting Things Done) indicate > that having a single place to manage your tasks is key. Also, this enables you > to have your task directory checked in (although it has been ages since I > worked that way myself). > Do you talk about sharing the task context among your team? Yes, it is a interesting idea, but I don't know if this is a "killer feature" I would like to have... > two different worksapces (work and home) since this is a common mode. So a > important question is, how should the task data be shared across those? Seems > like import/export at the start and end of every day is way too much trouble. > Yes, agree. I think the import/export should be used in the cases where you want to make/restore a backup of your data, or transport your history to another different workspace. Hi, (In reply to comment #2) > I am a user of the one task location, multiple workspaces. I like having the > list of all my tasks available in Eclipse to know all the things I should be > doing ( ;) ) even though I use separate workspaces for some of my projects. Yes, but for the "all" story, I use saved searches in bugzilla. Bugzilla contains all information. You can search, sort, etc. Even if bugzilla is a bug tracking system, not a project management tool, I don't think mylar should handle the "planning" story. It should be the bridge between the history of your code and some subject on the "task" repository (in my case, bugzilla). > > Since this is likely the less common case, the default maybe should be to make > it act like a normal plug-in and in preferences have to activate the shared > case? > Good ;-) This is an important discussion, and something that we need to consider supporting better for 0.6, so I've updated the description to continue using this report for such discussion. My personal belief is that fewer workspaces = better productivity (I used to have to work with 4, thanks to Mylar and working sets I only have 1 working workspace, and 5 others used only for build/test). But for some users this is not an option. Willian, have you considered using a single workspace with seperate working sets for your sets of projects (assuming you are using Eclipse 3.2, don't bother trying that with 3.1). If that won't work for you it would be useful if you could describe why. Also, note that while Mylar probably shouldn't handle the project/release/deliverable planning story (Bugzilla++ tools like CollabNet and Rally can do that), a key thing it does handle is the personal planning story (e.g. setting personal reminders, helping you prioritize which tasks to do today, working with personal tasks). While using this feature is optional, it does depend on a single location for that data. So we should continue doing a good job supporting the mode where you use Mylar as a way of querying the repository but keep all the state there, we still need to support the case where users (like me) use it to layer their own personal task management over what's visible in the repository. (In reply to comment #6) > This is an important discussion, and something that we need to consider > supporting better for 0.6, so I've updated the description to continue using > this report for such discussion. My personal belief is that fewer workspaces = > better productivity (I used to have to work with 4, thanks to Mylar and working > sets I only have 1 working workspace, and 5 others used only for build/test). > But for some users this is not an option. This is my case. > Willian, have you considered using a single workspace with seperate working > sets for your sets of projects (assuming you are using Eclipse 3.2, don't > bother trying that with 3.1). If that won't work for you it would be useful if > you could describe why. I have a set of many small projects which form a internal framework. Based on this framework there are some products. The problem is: the products use different version from my internal framework, so the only choice I have today is to mantain a workspace for each combination of product version + framework. Yes, I think that fewer workspaces == better too, but I figured out that this was the best (unique?) solution. Working sets would not work because there are many small subprojects in the framework (there is a good reason to be this way), and would be very complex to manage many branches of many subprojects of many products in the same workspace ;-) So, in my case, I organize my project set by workspace, and inside each project set, I separate the framework projects, product projects by working sets. I suspect this should be a very common use case. > > Also, note that while Mylar probably shouldn't handle the > project/release/deliverable planning story (Bugzilla++ tools like CollabNet and > Rally can do that), a key thing it does handle is the personal planning story > (e.g. setting personal reminders, helping you prioritize which tasks to do > today, working with personal tasks). While using this feature is optional, it > does depend on a single location for that data. So we should continue doing a > good job supporting the mode where you use Mylar as a way of querying the > repository but keep all the state there, we still need to support the case > where users (like me) use it to layer their own personal task management over > what's visible in the repository. > I agree, but I didn't understand yet what is the point in sharing data between workspaces (what is sooo cool... ;-). I hope someone could tell us about his personal experiences with this feature. (In reply to comment #7) > I agree, but I didn't understand yet what is the point in sharing data between > workspaces (what is sooo cool... ;-). > I hope someone could tell us about his personal experiences with this feature. Its a matter of work organization. I want one list of the tasks I need to do and one list in which I enter new tasks as they come up. I might not work on those tasks right away. When I decide to work on a task, the task tells me (by nature of what it says I must do) which workspace I need. So I want the task list shared between all of the workspaces I work with. While not quite a dependent bug, we need to watch bug 154097 for changes, since some of this workspace sharing functionality is scheduled for Eclipse 3.3. *** Bug 166288 has been marked as a duplicate of this bug. *** *** Bug 166271 has been marked as a duplicate of this bug. *** *** Bug 165961 has been marked as a duplicate of this bug. *** Here are a couple of different, though complementary, cases of why choice of single/multiple workspace and single/multiple task lists need to left be under user control (even though the current default of one-list-per-workspace is sensible): 1) because I'm developing an eclipse plugin to help some other development tasks - for developing/debugging the plugin need to have a separate workspace from using it (& whole separate eclipse instance as well, but that's neither here nor there) - so I switch between plugin development workspace and plugin use workspace. But I want to have a consistent set of tasks across these (both repository and non-repository tasks) 2) because I move betwen different Work-Projects (capitalized to indicate I do not mean eclipse projects here), I like to have tasks and contexts for these, but want to keep these quite separate, so that I can keep focussed on the individual Work-Project that I happen to be working on that hour/day/week... The job of switching between Work-Projects is not something I want dealt with by mylar (though clearly this is an individual preference / personal organizational feature). Tim: for (1) what we typically do is only have the task list in the "use" workspace, but this is partly facilitated by the fact that we work self-hosted: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Self-hosting Would that work for you? Regarding (2), we recommend managing separate sets of projects with Eclipse's Working Sets, and are planning on adding these working sets to the Task List (bug 153573). Would that support your use case? I work with two PCs, a Desktop with four screens for development and testing in the office (we work with lots of applications which require quad-screens), and a Laptop which I work on at home, and when integration testing (at supplier's premises overseas, and usually isolated from the internet). It is also common for me to not have the laptop with me at work. I simply do not have the option of a shared task list between both computers, as they often do not have network connectivity between each other, and exporting and importing tasks every single day is a major pain. I have been looking into alternative options for managing my tasks and am considering setting up a local (on my desktop) Bugzilla installation and using that purely as the master copy to synchronise my laptop and desktop to. The disadvantage is the loss of scheduling and context functionality with Bugzilla. I suggest, rather than adding complexity to Eclipse/Mylyn in managing multiple accesses to a single task list on the hard disc, that you look at a network-based solution with one master application responsible for managing the files. There are two possible solutions I can see... 1) Eclipse / Mylyn could be made into a client/server setup where one instance of Eclipse would have the task list files open, and the other instances of Eclipse would access that via a TCP connection. For this to work fully for me, the client Eclipse applications would need to cache this information locally, (as they do for Bugzilla) 2) The full Mylyn scheduling and context features could be added to Bugzilla and users wanting a task list across multiple Eclipse instances or PCs could install Bugzilla and get the full Mylyn functionality that way. I believe this bug/enhancement is causing my office all kinds of grief. A number of my developers work on a single remote box (Windows over RDP) with a single install of Eclipse on it. Each developer has their own workspace, and this is fine for all plug-ins except Mylyn. When one person logs into Jira through Mylyn it kicks the other users out and prompts them to login with the user name and password of the user that just logged in. We have also had instances of one developer making comments on tickets as another developer. This unfortunately makes Mylyn unusable for us at this point in time. D. Wolowicz, that sounds like a bug specific to the way JIRA handles user sessions that has not been reported before. Please file a new bug and include the version of the JIRA repository. Our current support for multiple workspaces is described at: http://wiki.eclipse.org/index.php/Mylyn/FAQ#What_if_I_use_multiple_workspaces.3F Going beyond that on that will likely require a workspace hosting service provider, which is out of the scope of Mylyn (as well as other Eclipse projects that would benefit from this). (In reply to comment #18) > Our current support for multiple workspaces is described at: > http://wiki.eclipse.org/index.php/Mylyn/FAQ#What_if_I_use_multiple_workspaces.3F We just started working with RAP and singlesourcing basically requires to have one workspace for RCP and one for RAP. In order to develop effectively one needs to have two eclipse instances running at the same time, one each for the two workspaces. This obviously does not work with the suggested "solution" in the wiki. As we also started using CDO for our new product and I wonder if Mylyn could use CDO to access the task list as in that case one could start a CDO server for the tasklist and both instances of Eclipse/Mylyn could access/modify the task list without stepping on each other, as CDO would handle the distributed aspect for it. Actually the first Eclipse to start could start the CDO server (if the port is not already taken) and all subsequent instances would only connect to the running server. Hi All. We have developers that work on one Citrix server. So they all use one Eclipse instance with multiple workspace at the same time. Is there any chance to make the repository Config workspace specific? |