Q:

Having two tables for capturing data at a specific moment

I'm creating an application which will hold curriculum vitaes 
the user should be able to: 
create different work information for using with different CV's
Name of work, Start date, End Date, ...
CV will have many WorkInformations
Workinformation belongs to many CV's
though when a user changes workinformation outside the scope of the CV I don't want it to change within the current CV's. 
Is it correct to have an extra table with the same information? 

Its supposed to create a new "workinformation" from a copy of a "workinformation_that_shouldent.."
or any other approach I should look into, open for all suggestions, new to designing relational databases. 

A:

No, I don't think you should have a different workinformation table. 
Instead, you should have the CV point to a work information record.   When the work information record changes outside the CV world, then create a new version of the record.   That way, all work information records are in the same table.   The ones that CVs refer to remain the same. 
You can keep track of different versions of the same record in more than one way.   A simple way is to have versions refer back to the base work information record, with another field having the version number. 
By the way, I find it unusual that a work information record would be referred to by multiple CVs. 