Bug 68642 - [Operations] "Replace With > Latest from TEST_BRANCH" replaces file with HEAD
Summary: [Operations] "Replace With > Latest from TEST_BRANCH" replaces file with HEAD
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: CVS (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P5 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: platform-cvs-inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2004-06-25 13:40 EDT by jens CLA
Modified: 2020-05-10 00:12 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jens CLA 2004-06-25 13:40:32 EDT
I have a sticky, modified (dirty flag) resource FILE_X.txt in my workspace (the 
parent folder is not sticky):

>FILE_X.txt 1.7.4.22 TEST_BRANCH

The repository conatins already a revision 1.7.4.24 (on the branch) and a 
revision 1.8 (on HEAD)!

(1) When I use Replace With > Latest from TEST_BRANCH I get the revision 1.8 
(latest from head) instead of latest from TEST_BRANCH!

(2) But when I use Replace With > Another Branch Or Version > TEST_BRANCH I get 
latest from TEST_BRANCH

(3) Is the parent folder sticky with TEST_BRANCH I get with (1) and (2) the 
correct result.

Why does the replace operation in case (1) use the stickyness of the parent 
folder?
Comment 1 Michael Valenta CLA 2004-08-16 09:55:25 EDT
This problem is due to how Eclipse performs a replace with. The only way we 
could ensure that the proper files were fetched on a replace was to delete and 
unmanage any files that are dirty. If this is not done, there are some cases 
where CVS will not replace the file (I seem to recall it is when the file has 
been removed from the server by a third party).

In this case, the file in question is deleted and unmanaged and so the tag of 
the parent is used to refetch it. There's not much we can do without changing 
the way the replace works. It may be possible to change the repalce to not 
remove the file before hand and then do some post processing based on the 
messages returned from the server to remove or fetch any files that were 
skipped.
Comment 2 Eric Layton CLA 2004-09-01 15:56:17 EDT
The functionality is consistent if you replace the text in the the action
"Replace With > Latest from Branch TEST_BRANCH" with something like "Replace
With > Latest from Current Branch".  That action will obey the sticky tags in
the parent directory.  If you want to resync everything to a new branch you'll
have to use the "Replace With > Another Branch or Version" action.

Can I suggest that the text be changed to reflect this?
Comment 3 Michael Valenta CLA 2004-09-01 16:50:01 EDT
Re comment #2: There are really two problems here. The first is that, when 
tags are mixed in a project, the Replace with and Compare with titles may not 
reflect the entire project since they only look at the top. This is the 
problem you are addressing. Making the title more generic doesn't help because 
I could just as easily have mixed version tags within a branch and Replace 
with Current Branch would be just as confusing. 

The second problem (the one which this bug is addressin) is that a file with a 
branch tag on it is being replaced with a file without the tag. This is 
clearly a bug and no change in menu name will help.
Comment 4 Jörg von Frantzius CLA 2005-03-03 07:17:57 EST
For me, a file without the branch tag is *not* replaced with the file that does
carry the branch tag, when I do "Replace With / Another Branch or Version..."

To put it more simple, I committed some changes to HEAD and then replaced only
my source folder with Branch "M15" (mixing tags in the project). Those changes
had not been committed to Branch "M15", but after replacing I still have the
changed files (latest HEAD) in my workspace. 

To me it looks like "Replace With / Another Branch or Version..." does not
recursively work on the contents of the folder I wanted to replace. I can
successfully replace on a file-by-file basis. 

As a sidenote, the CVS Resource History then *still* showed latest from HEAD
being the one in the workspace, although I linked it to the Editor. Pressing
refresh then correctly shows the file with tag "M15" being the one in the workspace.
Comment 5 Jörg von Frantzius CLA 2005-03-03 11:23:19 EST
Happens with 3.1 M5a
Comment 6 Eclipse Genie CLA 2020-05-10 00:12:54 EDT
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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.