Re: off topic: cvs diff within branch and repo copied files

Andreas Klemm <andreas(at)freebsd.org> wrote:

> > > $CVS -d $APSCVS diff -u --new-file \
> > > -r $reltag -r $branch \
> > > > $TMPDIFF 2> /dev/null
> >
> > Für welche Werte von reltag und branch?
>
> -r RELENG_7_0_1_RELEASE -r RELENG_7
     RELENG_7_1_0_RELEASE

Das ist wichtig, denn mit 7.0.1 gibt es das erwartete Ergebnis.

> setenv CVSROOT :pserver:cvs(at)apsfilter.org:/var/apscvs/APSCVS
> cvs login
> cvs checkout -r RELENG_7_1_0_RELEASE -P apsfilter
> cvs diff -u --new-file -r RELENG_7_1_0_RELEASE -r RELENG_7 > xxx

In der Tat...

> Das ganze funktionierte prächtig, bevor ich anfing,
> ein repository copy einiger files zu machen.

Falsche Fährte. Das Problem tritt bei den Originaldateien auf, nicht
bei den Kopien. Die repokopierten verhalten sich rundherum wie
erwartet.

Der Knackpunkt ist das Tag. Mit

diff -N -rRELENG_7_1_0_RELEASE -rRELENG_7

weist du cvs an, in jeder Repository-Datei nach dem Tag
RELENG_7_1_0_RELEASE zu suchen, und ein Diff von der zugehörigen
Revision zu der am Kopf von RELENG_7 zu machen; existiert eine
passende Revision nur auf einer Seite des Vergleichs, ist sie auf
der anderen für den Vergleich als existent und leer zu betrachten.

HOWTO-BUGREPORTS und die anderen Dateien, die nun unerwartet
auftauchen, sind auf RELENG_7 gelöscht worden, bevor das Tag
RELENG_7_1_0_RELEASE gelegt worden ist. Es taucht in HOWTO-BUGREPORTS,v
schlicht nicht auf. cvs vergleicht nun diese nicht vorhandene
Revision (leer) mit der letzten am Kopf des Branches. Warum es dabei
nicht berücksichtigt, dass diese <dead> ist, weiß ich nicht.

Dieses Verhalten ist reproduzierbar, auch direkt mit Revisionsnummern.
Macht man ein diff -N zwischen einer Revision, die nicht existiert,
und einer gelöschten, dann wird ein komplettes Diff zwischen einer
leeren Datei und dem letzte Stand der gelöschten ausgegeben. Ein
$Id$-Keyword enthält tatsächlich die Revisionsnummer der Löschung
(nicht die eins davor) und am Ende steht auch Status "dead".

Ich kann nicht sagen, ob das ein Bug oder ein Feature ist, aber
dieses Verhalten ist regulär.

-- 
Christian "naddy" Weisgerber                          naddy(at)mips.inka.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message