Community
Participate
Working Groups
The task is to synchronize a project that doesn't have CVS metadata with a CVS server, where the project already exists ( we had to move projects from one repository to another). The project on the local disk might have some files which are different from the versions in the repository. In this case Eclipse asks if it should synchronize the project with the repository, which is a good thing. Unfortunately finding the next steps is not very intuitive. Eclipse first shows that there are conflicts for all files. Since there is no common ancestor the 3 way comparsion view only shows red boxes. It would be better for example if Eclipse would switch to the 2 way view automatically. The next problem is that "override and update" just does an update( I learned that this is expected, but it's IMHO not obvious). One has to use the "Compare file Contents" menu, which is very difficult to find. Using this works more or less as expected. If only "Synchronize" menu is used the project get's never synchronized completetly. One has to do to a "manual" update or commit. Maybe Eclipse could warn the user or give it a hint that "compare file contents" should be used. I also noticed that when doing this somehow the history got incorrect dates and also sometimes just disappeared for some files.
We should do something for 2.1 even if it's just better help/doc
*** Bug 28290 has been marked as a duplicate of this bug. ***
I recently had to do just this, and the only way I managed to do it (and keep my sanity) was by moving outside the workspace idea altogether. I checked out a fresh copy of the repository sources into a new project, and then recursively copies the non-cvs controlled copy on top of the workspace managed files. Workspace->refresh, followed by CVS->Synchronise (which gave lots of non-existent local modifications, and a few conflicts), and a slow manual merge of the local sources, and I emerged with my sanity intact. It would be nice to be able to check out sources on top of an existing workspace, but I don't believe CVS would stand for it. It's quite difficult to see what semantics this would have... would you treat the local sources as a branch which got branched off from the initial version of the repository and do an update -j? How would you handle files with changes from the repository version? What version would you use for their baseline? Cheers, Dave.
The problem with using the "compare using file contents" option is that it doesn't modify CVS/Entries (to add files which actually exist in CVS, but which are marked as unknown locally). So, you end up with two possible outcomes: 1. Don't compare file contents -- this leaves you with a conflict or two ;-) 2. Comppare file contetns -- no conflicts are show, but Entries aren't updated, which means you have to resort to 1. After much pain, I think I've figured out a workflow which makes this all doable (remember, I'm working with a workspace > 10,000 files. going a file at a time is not feasible): 1. get a project without metadata 2. checkout the same project from CVS 3. copy the metadata-less project over the project with metadata 4. synchronize with repository Testing it right now -- I'll add a comment if it didn't go exactly as planned.
No, that didn't work as planned. Instead of conflicts, they're out-going changes. And, again, comparing file contents "hides" that fact, until you do a sync. without comparing file contents.
The following is a reasonable attempt... 1) Check out the CVS into a fresh directory structure 2) cd projectWithoutCVS; tar cf - . | (cd ../projectWithCVS && tar xf -) 3) refresh workspace 4) CVS update (not synchronise). This updates the Entries, and sets local status to Modified based on contents rather than timestamps. 5) Resolve conflicts, if there are any. 6) There is no 6. This is what I was getting at in my earlier comment, albeit not too clearly :) The trick is to avoid the Synchronise view most of the time, since it has a few problems... Cheers, Dave.
A small description was added to the doc for 2.1.
The sharing wizard has improvements in M8 which address these issues. When sharing against a project that exists, all files whose contents match that on the server are marked in-sync and the user is left to deal with only the files whose contents differ.
