Jim Blandy writes: > On 11/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
