Community
Participate
Working Groups
3.1 M2 The label "Latest from HEAD" in the Replace With and Compare With menus is misleading and can lead to errors: 1.inside a project replace a file with some other sticky revision (confirm the warning dialog) 2. select the project, Compare With > Latest from HEAD ==> no changes (unexpected) 3. select the project Compare With > Another Branch or Version, select HEAD ==> difference gets reported (expected) Instead of Latest from HEAD it might say something like "BASE REVISION".
Until we can show that there are mixed tags what ever we call this may be misleading. It used to say "Latest from Repository" which is but is what is going to happen with mixed tags. When you replace sticky the base is actually changing so your case 2 will still return no changes.
*** Bug 126340 has been marked as a duplicate of this bug. ***
It is not just "Latest from HEAD" but also menu entries like Compare With > 'some tag' are all inaccurate since it might not give the same (correct) result as Compare With > Another Branch or Version, then select 'some tag' Why not re-label them to e.g. Compare With > Current Tag(s) or: Compare With > Local Tag(s) ?
*** Bug 42509 has been marked as a duplicate of this bug. ***
I agree with Daniel we should call those differently. This would fix the bug. I disagree with Michael: I think it should be possible to find a good name that describe the situation well. However, "Current Tag(s)" or "Local Tag(s)" is not a good choice. These are phrases that are not in common use in the versioning scene - at least not as far as I'm familiar. (Show me those phrases in the Cederqvist CVS manual, e.g., http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs.html and I'd be convinced.) These terms are also misleading. A tag is a thing that lives in the repository, not in the workspace. It isn't local. How about: "Latest from Repository (current workspace branch)" ? Daniel: I have not understood what else goes wrong, besides "Latest from HEAD". How does Eclipse (mis-)behave?
>Daniel: I have not understood what else goes wrong, besides "Latest from HEAD". >How does Eclipse (mis-)behave? What I meant is that the same problem happens with any version/tag. Just repeat the steps from comment 0 with a project that is not from HEAD but e.g. version tagged 'v1' and replace 'Latest from HEAD' with 'v1'.
There are two ways to proceed on this: 1) Stop using tag names in the actions altogether. This is the easiest approach and I'm sure we could some up with suitable names but the names would never be as clear as using the tag names. Hence, for the case where users are not mixing tags (i.e. 99% of the time), this would be a regression in funtionality. 2) Somehow flag the folders that contain mixed tags so that the menu actions can be properly named. This is ideal from a functionality standpoint but complicated from an implementation standpoint. So, we stuck between causing a regression for 99% of our users vs. a complicated implementation to ensure that the name is correct for users who mix tags. How does this compromize sound? By default, the specific naming scheme involving tag names is used. However, if the user ever mixes tags in a project, that project is flagged and the menu options for it are always generic. The project would need to be tagged if a replace failed as well since that may leave mixed tags. However, any replace that succeeded at the project level could unflag it. This is still not trivial to implement but is not as complicaed as getting it right at the folder/file level.
Both 1) and 2) seem not to be a good path. What about a more pragmatic solution: why not adjust the code behind the menu items and leave the menu items as is i.e. if the user selects 'Latest from HEAD' simply compare it with the HEAD tag i.e. do the same as if I would pick Compare With > Latest from HEAD - same for versions. How does that sound? This would not confuse existing users and would reveal the rare case where mixed tags are in place and in addition this should be trivial to implement.
I like the idea but it would not support the case where the user is mixing branches and wants to keep up with both.
I know but if I may pickup your numbers from comment 7: >99% of the time users have one tag I'd add: 0.99% accidentally mix it 0.01% want this on purpose So, I guess it would be a good compromise. If you think this might be a problem for the 0.01% we could add a switch to choose between the two.
Yes, that though had crossed my mind. It's not quite as simple as that though since the behavior you suggest would actually change the semantics of the underlying operation. At the current time, the operations in question do a "cvs update" with no tag. We would have to switch to providing a tag and this could lead to subtle changes in the operation that is not anticipated by the operation. We'll investigate for 3.3 and see how doable this is.
> I'd add: > 0.99% accidentally mix it > 0.01% want this on purpose I disagree. Ok, there are many people who use CVS only in a "single time line" fashion. They never branch nor merge. They are not all that concerned with the outcome of this bug. For those that do use branch+merge functionality, unfortunately, branching the entire project is a fairly expensive operation (in CVS). Both technically: It takes some time. And also socially: As creating a branch changes every single file in the project. In my projects, I recommend using branches freely. But this leads to lots of branch labels all over the files. This is a price to be paid. And it is fairly difficult to clean up branch labels that are no longer needed. If you do, you loose the ability to go back in time, to those days when that particular label was still used. So, while still using CVS (as opposed to SVN, which addresses these issues), there are good reasons to branch only a certain part of a project. Or even only a single file. I do this occasionally. While I consider myself a versioning power user, I don't think mixing branches is that odd a thing to do, as your "1 in 10000" suggests.
(In reply to comment #8) > Both 1) and 2) seem not to be a good path. What about a more pragmatic > solution: why not adjust the code behind the menu items and leave the menu > items as is i.e. if the user selects 'Latest from HEAD' simply compare it with > the HEAD tag i.e. do the same as if I would pick Compare With > Latest from > HEAD - same for versions. This would be conceptually clean. But, in my opinion, plain vanilla Eclipse menu items should offer the same functionality that CVS users have come to expect from plain vanilla CVS usage. Do the particular thing only if that thing has been paticularily asked for. > I like the idea but it would not support the case where the user is > mixing branches and wants to keep up with both. Yes! This is a fundamental CVS operation. It is easily available in plain vanilla CVS. For a reason. It should be easily available in Eclipse, too. > 1) Stop using tag names in the actions altogether. This is the easiest > approach and I'm sure we could some up with suitable names but the names would > never be as clear as using the tag names. Hence, for the case where users are > not mixing tags (i.e. 99% of the time), this would be a regression in > funtionality. I'd pay that price. Be as simple as precision allows, but not simpler. Personally, I'd even say that using a tag names when you don't actually mean that tag is NOT clear. It confuses people, and keeps them from understanding what version management is really good for.
We do not plan on addressing this issue in 3.3.
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. -- The automated Eclipse Genie.
