Changes to a file are not picked up outside of RTC?
Hey guys,
As you can probably tell from my last post, I'm using Jazz version control to store some documents.
However, I'm editing these documents outside of RTC since they are Word and/or text documents.
I saw some behavior that was pretty surprising.
1. A Word 2007 document gets corrupted after editing in RTC.
2. Changes to a text file made outside of RTC show up as 'unresolved' changes.
In the first case, I added a Word document to my project. I delivered the change set to my stream so there were no pending changes. I edited the document in Word and noticed that there were no pending changes. I double-clicked on the document in RTC and saw an embedded Word document. I made some changes and saved. Then there was a pending change. I delivered that and double-clicked on the Word document again. At that point I couldn't open the Word document in Word or RTC anymore.
In the second case, I added a text file to my project and delivered my change set. I then made some changes in another editor. When I looked at my pending changes, it told me that there were unresolved changes. I worked through the dialog and was able to check-in.
It struck me as being unnecessarily limited to force people to always edit in RTC. Is this the expected behavior? If it is, that is fine, I'll have to find another solution for my documents. Any background on why this is the case would be appreciated as well.
Thanks!
Eric.
As you can probably tell from my last post, I'm using Jazz version control to store some documents.
However, I'm editing these documents outside of RTC since they are Word and/or text documents.
I saw some behavior that was pretty surprising.
1. A Word 2007 document gets corrupted after editing in RTC.
2. Changes to a text file made outside of RTC show up as 'unresolved' changes.
In the first case, I added a Word document to my project. I delivered the change set to my stream so there were no pending changes. I edited the document in Word and noticed that there were no pending changes. I double-clicked on the document in RTC and saw an embedded Word document. I made some changes and saved. Then there was a pending change. I delivered that and double-clicked on the Word document again. At that point I couldn't open the Word document in Word or RTC anymore.
In the second case, I added a text file to my project and delivered my change set. I then made some changes in another editor. When I looked at my pending changes, it told me that there were unresolved changes. I worked through the dialog and was able to check-in.
It struck me as being unnecessarily limited to force people to always edit in RTC. Is this the expected behavior? If it is, that is fine, I'll have to find another solution for my documents. Any background on why this is the case would be appreciated as well.
Thanks!
Eric.
2 answers
You should always be able to use any editor to modify/view your files
under RTC version control. You lose some Eclipse-specific behavior
(such as the optional auto-checkin-on-save behavior), but otherwise
everything should work in a natural/intuitive way.
The first case is a (serious) bug ... a file should never be corrupted
after editing in RTC. Is this reproducible? Please submit a defect
report. (There were some reports on problems with word documents
through the web browser interface, so I don't know if this might be
related to that ... the Jazz SCM folks will probably know).
In the second case, a non-checked-in change is called an "unresolved
change" in the Pending Changes view. In particular, this is how you'd
see those changes with a native Eclipse editor when you turn off the
"auto-checkin-on-save" behavior. Other SCM systems would just call
those "checkouts". If you find this aspect of the GUI confusing, please
submit a defect/enhancement request.
Cheers,
Geoff (ClearCase Connector team)
ericlee wrote:
under RTC version control. You lose some Eclipse-specific behavior
(such as the optional auto-checkin-on-save behavior), but otherwise
everything should work in a natural/intuitive way.
The first case is a (serious) bug ... a file should never be corrupted
after editing in RTC. Is this reproducible? Please submit a defect
report. (There were some reports on problems with word documents
through the web browser interface, so I don't know if this might be
related to that ... the Jazz SCM folks will probably know).
In the second case, a non-checked-in change is called an "unresolved
change" in the Pending Changes view. In particular, this is how you'd
see those changes with a native Eclipse editor when you turn off the
"auto-checkin-on-save" behavior. Other SCM systems would just call
those "checkouts". If you find this aspect of the GUI confusing, please
submit a defect/enhancement request.
Cheers,
Geoff (ClearCase Connector team)
ericlee wrote:
Hey guys,
As you can probably tell from my last post, I'm using Jazz version
control to store some documents.
However, I'm editing these documents outside of RTC since they are
Word and/or text documents.
I saw some behavior that was pretty surprising.
1. A Word 2007 document gets corrupted after editing in RTC.
2. Changes to a text file made outside of RTC show up as 'unresolved'
changes.
In the first case, I added a Word document to my project. I delivered
the change set to my stream so there were no pending changes. I
edited the document in Word and noticed that there were no pending
changes. I double-clicked on the document in RTC and saw an embedded
Word document. I made some changes and saved. Then there was a
pending change. I delivered that and double-clicked on the Word
document again. At that point I couldn't open the Word document in
Word or RTC anymore.
In the second case, I added a text file to my project and delivered my
change set. I then made some changes in another editor. When I looked
at my pending changes, it told me that there were unresolved changes.
I worked through the dialog and was able to check-in.
It struck me as being unnecessarily limited to force people to always
edit in RTC. Is this the expected behavior? If it is, that is fine,
I'll have to find another solution for my documents. Any background
on why this is the case would be appreciated as well.
Thanks!
Eric.