[darcs-users] -p behaves inconsistently

[stephen at xemacs.org]

Jim Blandy writes:

 > On 11/7/06, stephen at xemacs.org <stephen at xemacs.org> wrote:

 > > For it to work in a "reasonable" way, Darcs needs to "know" about
 > > ChangeLogs, in the same way that it needs to "know" about token
 > > replacement.
 > >
 > > There's nothing wrong with that, IMO, but AIUI David doesn't want more
 > > such special cases.

 > Would this special knowledge assemble ChangeLog entries by the date
 > they entered the repository, or by the date they were first recorded,
 > or what?  It would need to be based on the date somehow, right?

I don't think so.  The entry's date documents when the patch was
written.  The commit date, and ChangeLog order, documents when it was
applied.  These don't have anything to do with patch management, IMO.
So I don't see why Darcs would need to know anything about dates;
that's the committer's problem.

Because of the nature of Darcs patches as (in general) whole-tree
patches, you'd have to expect "local" instability in ChangeLog order
across repositories and branches.  I'm not sure about the implications
for patch reordering in resolving conflicts.  You'd also need to
discipline committers to always revert, rather than unrecord, patches
across "milestones" like releases, at least if you put banners into
the ChangeLog as most projects do.

So the "special knowledge" would simply be the ability to recognize
files that are ChangeLogs, and to parse the ChangeLog sufficiently to
make each log entry an "atomic" unit.  These units would not consider
context, and they are always added at the same end of the ChangeLog.
I'm not sure whether deletions or adds in the middle should be
supported.  I don't think these would cause the same kinds of
conflicts, though, so probably they can be left for later.  The
changelog patch type probably should be able to handle both top-latest
and bottom-latest ChangeLog orders as an option, and should allow at
least constant prefatory material (eg, a copyright notice) in the
top-latest case.

I don't see any way to avoid problems with *changing* a log entry,
though.  The changelog patch type I have in mind would consider that a
new entry, not a changed entry.  So anything like that would need to
be an ordinary patch.

That's as far as I've taken it, and I'm completely incompetent to
write any Haskell code to implement it.

HTH

Steve