gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] replay in a tags-only branch considered harmful?


From: Andreas Fuchs
Subject: [Gnu-arch-users] replay in a tags-only branch considered harmful?
Date: Thu, 05 Feb 2004 22:29:45 +0100
User-agent: Wanderlust/2.11.20 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI)

Hi all,

I think I just fell into a pitfall by following (more or less)
<URL:http://regexps.srparish.net/tutorial-tla/symbolic-tags.html>:

I had created a "release" branch for my pet project, iterate. The
release scripts that I wrote would tag over a version from the "main"
branch when I created a release, then run "tla replay" in a working
directory, then do some magic and create&upload a tar file. Only that
the replay never replayed any changes (except adding the patch log of
the concerned revisions from the "release" branch). The branch in
question is in my archive at
address@hidden/iterate--release--1.0
(http://arch.boinkor.net/address@hidden/)

James Blackwell and Robert Collins together tried to debug this with
me in IRC and came to the conclusion that "tla replay" is not a
sensible operator on tags-only branches. However, "tla update" does
the right thing.

AFAICT, this is because replay tries to just apply the changes to
Modified-Files that a new revision has made. Given a tags-only branch,
there are no Modified-Files, only Continuations.

tla update, however does not mess up, because it first computes a
changeset between the revision of the working directory and the target
revision and then applies that.


tla replay, as a lower-level operator, can't know what is necessary to
bring the project tree up to date. So, would it make sense to make
replay fail when it should replay to (or through) a Continuation
revision?

Even if it makes sense, I suggest adding another "Usage Caution" note
in the Symbolic Tags chapter of the tutorial to mention the problems
that replay could cause on a tags-only branch.

Thanks (especially to jblack and rbcollins for patiently debugging
this with me),
-- 
Andreas Fuchs, <address@hidden>, address@hidden, antifuchs





reply via email to

[Prev in Thread] Current Thread [Next in Thread]