Apache OpenOffice (AOO) Bugzilla – Issue 22379
cvs rdiff does not work
Last modified: 2003-12-06 14:52:32 UTC
cvs rdiff does not work, please see issue 3021 for reference
Opened internal staging issue pcn 24010
The underlying absolute path changes from SC 1.1.3 to 2.6.x. This is hidden from CVS client operations by the use of symbolic links. But for r* commands, the user must specify the new absolute, non-symlinks path. The new real path is "/shared/data/ccvs/repository"
mh->hr: how is the impact to our tooling ?
The change in the path will break things again for all developers. I'll have to change tools for that. I would have to educate all the developers to extend their .cvspass. Why can't we have r-commands which work like supposed? The workarounds for this long standing problems have already caused man weeks in lost time.
Please note, that the issue is in state resolved/fixed. I would recommend to reopen, if you think that a chnage of the new behaviour is needed.
reopen
We would like to further understand the impact of this change. Setting up the old absolute path would create a non-standard, unsupported use of CVS for this version of our product. A future version of our product will provide absolute path name flexibility, but for now the absolute path name is as specified. Do all users use r* commands? Or are the tools modified once and disseminated to the developers? To what degree is this an annoyance or a major problem?
the rdiff command is used by almost all users on regular basis. the rdiff command provideds analysis possibilities in our child work space scenario we implemented upon cvs. the current server implementation of ooo cvs does not provide any help that the standard behavior of cvs has been changed for OOo. Even worse, the displayed error message doesn't help the user at all. so we would need to train all users of ooo cvs to add their login to cvs with this specific r* path and we are also not able to explain, why collab's implementations of cvs differs from the standard. this is very error-prone and anoying.
Thank you for the feedback. I have forwarded this information to CN engineering. We are currently evaluating ways to resolve this.
We have determined a way to resolve this so the original absolute path will work for the 2.6.2 install. Please confirm on the next OOo stage.
verified on new stage
closing