Missing file history entry after revert

[marioo]

1. Go to the history of any file in your branch.

2. Right click some historical revision of the file.

3. Choose 'Revert to this revision'.

4. In the 'Pending changes' view you will see that the file is modified. Check it in as is.

5. Go to the history of the file again and you will see that the last check-in is not listed there.

6. Go to the last changeset in the current branch and you will see that the file is accessible there and you can view how it changed in the last check-in.

 

Isn't that a bug? If you revert a file to its historical revision and check it in, that action is not added to the history of the file.

[manu]

Wow, the topic name stopped my heart, I thought that all the history file was, somehow, gone. 

 

Let's explain what it going on and why a new revision is not created.

 

When you revert your file to a given revision, let's call it X, you are loading the revision X inside your workspace but the revision X is unchanged, the content of the file is the X revision file content. So why do we need to create another revision X+n with the same data as the X revision? We don't need it... so we don't create it, we replace the revision scm metadata.

 

But why do we need to create a new changeset? We create a new changeset because the parent directory has noticed the change, now it's loading the revision X so we need to commit that directory change.

 

Things that I can understand that can be weird.

 

1) The pending changes view says that the file is changed after the revert operation -> Half true, it's changed if we compare the X revision content with whatever was before. But it's not truly change due to we are loading the raw content of a revision.

2) A new changeset is created showing again the differences of the file -> Same explanation as before.

3) The history is not incremented with the new "revision" -> There's no new revision, we are pasting the revision X content and scm metadata.

 

Hope it helps!

[marioo]

I didn't mean to hurt you with the topic, sorry .

 

I think I understand what you are trying to say and it sounds reasonable. But I felt really confused when I noticed that the revert action was not present on the list. I may be wrong, but I understand file history as all consecutive states the file has been in. Each state is a result of a check-in. Therefore no matter is it a revert or a manual modification, I would expect it to be there, because the state (the content) actually changed.

 

When you analyse the situation the way you are explaining, that behaviour seems to be understandable. But from the point of the user, you have no complete trace how user's actions influenced the content of the file during its life time. Am I right?

 

I feel quite confused, but I'm no specialist. I rely on your experience.

[marioo]

An example file revision history:

1

2

[3] I revert the file to revision 1 (but this entry is not present here on the list)

 

According to the list above, the state of the file changes this way: 1 -> 2 -> 1. I know the last step (-> 1), because the first item is bold. It means that this is the current revision the file is in, right?

 

When I modify the file and check it it, the revision history will look like this:

1

2

4

 

The list tells me that the states of the file were as follows: 1 -> 2 -> 4. But in fact the file was in four states, right? 1 -> 2 -> 1 -> 4.

 

What I'm trying to say is not that your assumptions concerning creating revisions are wrong. They aren't. But I think the history displayed to the user should tell you about all states the file was in. I may be wrong, but this is what I feel right now .

[marioo]

Or let's forget it. The more I'm thinking about it the more I'm convinced that you are right and I'm wrong .

Thank you for your assistance and sorry for the confusion I may have caused.

 

If you think the topic is exaggerated, please feel free to change it.

[manu]

Don't worry Marioo! We are here to help and discuss!