Hi all, [Just using what Zooko/VMiklos brought up to get my word in]
Juliusz Chroboczek wrote in reply to Zooko: >>One way to look at it is that "darcs changes" is showing you the >>history of how your local repo changed. If today you pull a patch >>P1 that was written in 2005, and tomorrow you pull a patch P2 that >>was written in 2004, then running "darcs changes" will help you >>remember that there was a time when you had P1 but not P2, and then >>a later time when you had both. >> >> > >This is correct, and this is without doubt the way |darcs changes| >should behave when given no arguments. > >On the other hand, it should be possible to ask |darcs changes| to >sort the patch chronologically up to patch dependence. > > Zooko also wrote (with different intention): >Another way to look at it is that you have no way to be sure when patches were >actually created. > > ...and in which context they were created. So it would also be very nice if the *original* context info of a patch could be extracted. (I don't think it is in the current patch/repo format, is it?) Why? Well, just as one example, it allows for nice branch visualization tools just like git has (git-viz et al.). Another thing is that this makes explicit to other tools (bridges to/from other SCMs for example) what part of the actual diffs (the effects) are contributed by darcs merges. Example. Suppose my repo is in state C (for "context"), and I use "darcs replace" to replace "me" by "myself"; and suppose this affects just one line in the repo. This results in C2. Someone else introduces "me" from C, resulting in C3. Moving one of those patches to the other repo results in darcs merging, and C4. The diff between C and C4 is: change of "me" to "myself", plus introduction of "myself". The diff of the "naive merge", as seen by an outsider without an implementation of "darcs replace", would be: change "me" to "myself", plus introduction of "me". So from the point of view of this outsider, in the merge darcs silently changed "me" to "myself". I think this extra piece of knowledge would be good to have. And for that also one would need the original context info of the patches. But I don't have an example of a tool/bridge that would need this. (Except for an inter-SCM exchange file format that I'm thinking about, every now and then.) (Aside: git also hides this kind of knowledge, more or less. A git 'commit' --if I understood correctly-- basically says: this source tree has been derived from these others. Usually there is just one 'parent' tree. But if there are multiple parent trees, then it is unclear which part was *really* changed in the resulting tree, and which was simply the effect of automatically merging the parent trees. Especially in the git case, the 'real' change seems useful when reviewing.) (And for the curious: yes, if the above is to make sense one has to have an auto-merge algorithm at the diff level that always leads to a sensible result; perhaps with conflict markers in the result.) Groetjes, <>< Marnix _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
