In message <address@hidden> on Mon, 10 Apr 2006 22:36:44 +0100, Joel Crisp
<address@hidden> said:
jcrisp> I think you might have missed the point slightly...If I
jcrisp> understand this correctly, he made the changelog in the past
jcrisp> incorporating reversion hashes which have now changed due to
jcrisp> the 'rostification' of the database....so the historical fact
jcrisp> is that he HAS written down specific hashes which have now
jcrisp> changed.
Actually, he's talking both about automatically generated changelogs
(that's what I understands that he means with "propage Changelog
entries") and changelogs that he write himself that include a revision
hash, and it's for the latter that I'm asking why he feels the need
to, so I can understand that particular situation better.
jcrisp> In which case, your comment about the relevancy is accurate,
jcrisp> but inapplicable.
I disagree. For the automatic changelogs, it's absolutely
applicable.
jcrisp> On the other had, montone clearly states it is not a 1.0
jcrisp> product, so anyone using it must be aware that the only
jcrisp> certain thing is change.... ;-)
Yup, that's quite true.
jcrisp> Richard Levitte - VMS Whacker wrote:
jcrisp> > In message <address@hidden> on Mon, 10 Apr 2006 17:25:56 +0200, Tom Koelman
<address@hidden> said:
jcrisp> >
jcrisp> > tkoelman> Another thing I noticed is that, understandably, all
jcrisp> > tkoelman> revision hashes have changed. This has the unfortunate side
jcrisp> > tkoelman> effect that propage Changelog entries make no sense anymore,
jcrisp> > tkoelman> as they contain two revision hashes from the old database.
jcrisp> > tkoelman> Also, some of my handwritten changelog entries have the same
jcrisp> > tkoelman> problem. Is there some way in which I can replace these old
jcrisp> > tkoelman> revision hashes with their new counterparts?
jcrisp> >
jcrisp> > You can add a comment if you wish, but that really just pushes it into
jcrisp> > the future, if there's another rebuild needed. The revs in the merge
jcrisp> > and propagate changelogs are really irrelevant, the ancestors of the
jcrisp> > merge/propagate are registered separately, and are always correct. Of
jcrisp> > course, that doesn't help your hand written changelogs, but then, in
jcrisp> > what situations do you end up writing down a specific revision hash?
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
smime.p7s