Duplicate workspace ?
![]()
Can anyone tell me why I would want to duplicate a workspace? It seems to me it only creates a duplicate on the server not on my local system.
Is there a way I could use this to duplicate a local workspace *and* server workspace so I would not need to download all twice to have two workspaces to work with? It would appear to me I'd need to copy my local workspace yet and then still associate that with the new duplicate workspace created on the server. Thanks |
6 answers
![]() Can anyone tell me why I would want to duplicate a workspace? It seems to me it only creates a duplicate on the server not on my local system. Having a copy of your repo/local workspace pair does sort-of make sense if you want to keep a view of the code at one point in time on your local machine, and then make changes to the duplicate. In that case, the local workspace would be in two Eclipse workspaces and you would switch workspaces to go between them. However, in this case, I would just use baselines and snapshots and roll back and forth between the two points - then at least you are only downloading changes to your local machines. The whole repo/workspace pair concept removes most of the reasons I can think of right now. Did you want to have a duplicate workspace (and if so - why?) anthony |
![]() Can anyone tell me why I would want to duplicate a workspace? It seems to me it only creates a duplicate on the server not on my local system. Having a copy of your repo/local workspace pair does sort-of make sense if you want to keep a view of the code at one point in time on your local machine, and then make changes to the duplicate. In that case, the local workspace would be in two Eclipse workspaces and you would switch workspaces to go between them. However, in this case, I would just use baselines and snapshots and roll back and forth between the two points - then at least you are only downloading changes to your local machines. The whole repo/workspace pair concept removes most of the reasons I can think of right now. Did you want to have a duplicate workspace (and if so - why?) anthony Two reasons (though I honestly don't think for this I should need a reason it's not too far fetched IMO) I work on two or more entirely separate parts of the stream. I want to keep them ENTIRELY separate. I don't care to play with change set and snapshot, baselines and rollbacks to do that. Checking out full stream is a real pain (hours). The other case is really doing snapshots I spend hours getting full source only to find someone has really trashed it and I don't want to spend a weekend figuring out why they broke it. I've tried snapshots for that, but in the end it only seemed to mess up my WHOLE workspace. The only way was luckily I did a patch of my work and did a whole checkout and reapplied that patch (PAIN). No doubt, you'll say I messed up ... I'll grant you that. I'd MUCH prefer to have something more tried and true (for me). Let me TRULY duplicate (clone) my workspace. This includes my local workspace and what its associated on the the server. When I do and update and find out it the current state is hosed, I simply start up up rtc with my saved away clone and wait till its fixed. Is that too much to ask for ? |
![]()
You can duplicate other people's workspaces as well.
One use I use is that when a build fails, I duplicate the build workspace to get the complete environment to reuse. Also, duplicating workspaces allows for you to get access to changes that you may otherwise have a hard time getting a hold of (open, active change sets get cloned). Think of it as getting a copy of some potentially unfinished work. :-) Hope that helps, JohnC .. wrote: Can anyone tell me why I would want to duplicate a workspace? It seems |
![]() Can anyone tell me why I would want to duplicate a workspace? It seems to me it only creates a duplicate on the server not on my local system. Having a copy of your repo/local workspace pair does sort-of make sense if you want to keep a view of the code at one point in time on your local machine, and then make changes to the duplicate. In that case, the local workspace would be in two Eclipse workspaces and you would switch workspaces to go between them. However, in this case, I would just use baselines and snapshots and roll back and forth between the two points - then at least you are only downloading changes to your local machines. The whole repo/workspace pair concept removes most of the reasons I can think of right now. Did you want to have a duplicate workspace (and if so - why?) anthony Two reasons (though I honestly don't think for this I should need a reason it's not too far fetched IMO) I work on two or more entirely separate parts of the stream. I want to keep them ENTIRELY separate. I don't care to play with change set and snapshot, baselines and rollbacks to do that. Checking out full stream is a real pain (hours). The other case is really doing snapshots I spend hours getting full source only to find someone has really trashed it and I don't want to spend a weekend figuring out why they broke it. I've tried snapshots for that, but in the end it only seemed to mess up my WHOLE workspace. The only way was luckily I did a patch of my work and did a whole checkout and reapplied that patch (PAIN). No doubt, you'll say I messed up ... I'll grant you that. I'd MUCH prefer to have something more tried and true (for me). Let me TRULY duplicate (clone) my workspace. This includes my local workspace and what its associated on the the server. When I do and update and find out it the current state is hosed, I simply start up up rtc with my saved away clone and wait till its fixed. Is that too much to ask for ? Unless I have missed something in RTC - you can't just clone a local worksace without working from a repo worksspace- which is the capability I think you wanted from the first post. Definitely raise a work item on this. Not too sure how much you have used RTC at this point - so apologies in advance if this is something you are comfortable with already.... Making it really easy to have a safe state to go back to (quickly) is absolutely what RTC is very good at. The whole local/repo workspace idea is very good in that you If you want a space you can switch to without downloading anything new - I would create another Eclipse workspace and have that set up in the way you want it. Switch back to your original Eclipse workspace when you want to carry on working, and switch back to the "cloned" Eclipse workspace if you ever need to revert to your safe setup. The safe workspace will also have all the pending changes from other people waiting to be accpeted (or ignored) - so you have a pretty good chance of seeing what broke your workspace too. Also - using the Components idea (each component is one or more Eclipse projects), you can cut down the amount of downloading needed if you do need to pull down parts of a working version rather than everything. What took me a while to get into my head when I started using RTC was the idea of checking in files to the server and Again - apologies if this is something you already know, and I have misunderstood the original intent of the questions. anthony |
![]()
I think Anthony gives a very good overview of how we use RTC and why we don't really create new local file areas (aka, sandboxes) often.
However, I like your idea. When you do clone or load, why can't we be smarter and use any files that are already on your disk instead of having to fetch them from the server. 81250: When loading a workspace, either because of clone or another branch, take local copies first Cheers, Jean-Michel |
![]() Can anyone tell me why I would want to duplicate a workspace? It seems to me it only creates a duplicate on the server not on my local system. Having a copy of your repo/local workspace pair does sort-of make sense if you want to keep a view of the code at one point in time on your local machine, and then make changes to the duplicate. In that case, the local workspace would be in two Eclipse workspaces and you would switch workspaces to go between them. However, in this case, I would just use baselines and snapshots and roll back and forth between the two points - then at least you are only downloading changes to your local machines. The whole repo/workspace pair concept removes most of the reasons I can think of right now. Did you want to have a duplicate workspace (and if so - why?) anthony Two reasons (though I honestly don't think for this I should need a reason it's not too far fetched IMO) I work on two or more entirely separate parts of the stream. I want to keep them ENTIRELY separate. I don't care to play with change set and snapshot, baselines and rollbacks to do that. Checking out full stream is a real pain (hours). The other case is really doing snapshots I spend hours getting full source only to find someone has really trashed it and I don't want to spend a weekend figuring out why they broke it. I've tried snapshots for that, but in the end it only seemed to mess up my WHOLE workspace. The only way was luckily I did a patch of my work and did a whole checkout and reapplied that patch (PAIN). No doubt, you'll say I messed up ... I'll grant you that. I'd MUCH prefer to have something more tried and true (for me). Let me TRULY duplicate (clone) my workspace. This includes my local workspace and what its associated on the the server. When I do and update and find out it the current state is hosed, I simply start up up rtc with my saved away clone and wait till its fixed. Is that too much to ask for ? Unless I have missed something in RTC - you can't just clone a local worksace without working from a repo worksspace- which is the capability I think you wanted from the first post. Definitely raise a work item on this. Not too sure how much you have used RTC at this point - so apologies in advance if this is something you are comfortable with already.... Making it really easy to have a safe state to go back to (quickly) is absolutely what RTC is very good at. The whole local/repo workspace idea is very good in that you If you want a space you can switch to without downloading anything new - I would create another Eclipse workspace and have that set up in the way you want it. Switch back to your original Eclipse workspace when you want to carry on working, and switch back to the "cloned" Eclipse workspace if you ever need to revert to your safe setup. The safe workspace will also have all the pending changes from other people waiting to be accpeted (or ignored) - so you have a pretty good chance of seeing what broke your workspace too. Also - using the Components idea (each component is one or more Eclipse projects), you can cut down the amount of downloading needed if you do need to pull down parts of a working version rather than everything. What took me a while to get into my head when I started using RTC was the idea of checking in files to the server and Again - apologies if this is something you already know, and I have misunderstood the original intent of the questions. anthony thanks for you're reply. I have not been able to figure out how you associate a local diskcopy to a duplicated workspace. It seems as though the only way is to reload the duplicate workspace which then downloads everything... defeats doing the local diskcopy to avoid doing the (painful) download. I guess I'm hesitant about the snapshot and checking in partial results in a changeset even if its your own private area. I would be glad to see an option on a clone to also clone the local repo with it. Thanks everyone |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.