Community
Participate
Working Groups
When working with remote slow connections and large projects, using the merge feature against a remote server is a non-starter. Instead it would be useful to check out two branches and then merge against a local project repository. The added advantage is that this merge featuere would work across different types of source control systems, e.g. CVS/SVN.
I've never experienced such a problem but it doesn't mean I don't belive it occurs. What in your opinion would be the best way to change that inconvenience? My first thought was to check whether merging process takes more time than expected and inform a user that he or she can try what you suggested (check out two branches and merge them locally). We could also provide a wizard to make the "double check out and merge" a little bit easier.
(In reply to comment #1) > I've never experienced such a problem but it doesn't mean I don't belive it > occurs. What in your opinion would be the best way to change that > inconvenience? My first thought was to check whether merging process takes more > time than expected and inform a user that he or she can try what you suggested > (check out two branches and merge them locally). We could also provide a wizard > to make the "double check out and merge" a little bit easier. I think it would be *plenty* if the merge functionality actually worked with local projects. The way a checkout would occur in this case might be to download a single file and unzip it locally, ref. all those open source projects out there that have CVS snapshots, i.e. Eclipse might no be involved *at all*. The CVS snapshot would be downloaded once for each site and then copied from the LAN to each of the developer machines.
E.g. the CVS snapshot(s) could be downloaded nightly via batch job.
I would interpret this request as saying that CVS is a centralized repository and it would be nice (not to mention fashionable) to implement a more distributed model. While I agree that this would be useful, the unfortunate truth is that we do not have the manpower to pursue this type of work. However, we would be happy to work with anyone who wanted to tackle this.
(In reply to comment #4) > I would interpret this request as saying that CVS is a centralized repository > and it would be nice (not to mention fashionable) to implement a more > distributed model. While I agree that this would be useful, the unfortunate > truth is that we do not have the manpower to pursue this type of work. However, > we would be happy to work with anyone who wanted to tackle this. This is not my intent. In fact, we need this more urgently for Subversion and not CVS. I can't see how distributed CVS would fall into Eclipse's domain... I've corrected the summary. I want, for a number of reasons, Merge to work with another local project(or even better, any directory inside or outside the workspace Eclipse project or not) as well as against a repository.
OK, I'll try again. Are you asking for the ability to compare 3 folders and then merge all the differences from one side to another If so, I think this is a duplicate of bug 189654.
(In reply to comment #6) > OK, I'll try again. Are you asking for the ability to compare 3 folders and > then merge all the differences from one side to another If so, I think this is > a duplicate of bug 189654. I would say yes to the first part of your statement, but no to that it is a duplicate. Are you sure you are referring to the right bug? It seems completely unrelated. >
Created attachment 73926 [details] Merge requester I would like to be able to specify directories instead of tags in the view above. This would a) be faster for slow/allow offline work b) work w/SVN
I've updated the title and added a comment to bug 189654 to broaden the scope of that bug to include both overwrite and merge. However, I can see that having a separate merge operation could be useful as well.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
