[replying to two mails at once] On Wed, Dec 13, 2006 at 10:48:59AM +0100, Didier Verna wrote: > There was one oddity in the process: at the end of all the pulls from the > original repository, Darcs asked me if I wanted to pull several tags I just > did (and pushed as of step 3). I answered yes, out of puzzlement, and ended up > with duplicate tags in my changes.
I can not explain this. A tag is just a normal patch at some deep level of darcs, so either darcs pulled patches already in the repo, which would be a serious bug, or the patches somehow got changed into different patches at some point, which would also be a bug. Can you reproduce this strangeness? > 1/ After the process, I pushed my new repository to the old one, which made > the tags appear in the changes, but last. I thought that `darcs optimize > --reorder-patches` would place them at the expected place in the history > (meaning, right after all the patches they depend on), but no. They're still > appearing last. Is it normal ? I guess it is, but it's surprising. I'm not sure, but I think Optimize --reorder only works its way back to the "latest" tag. So if the latest tag covers all current patches, there will be no reordering at all. You could try to Obliterate the latest tag (if it's still in some other repo so you can pull it back again) and redo the optimization without it. Then presumably every patch not tagged by the "latest but one" tag will jump to the end of the changes. > 2/ When tagging, I also used the --checkpoint flag for people to be able to > optimally retreive just stable versions. I couldn't find a way to display, for > a given repository, the places where checkpoints are placed. Is there one ? No. (But you could make a wish for it on bugs.darcs.net, if it hasn't been done already.) On Wed, Dec 13, 2006 at 11:29:24PM +0100, Benjamin Franksen wrote: > I have been asking myself the same question as the OP. The proposed > procedure will probably work correctly in this special case, but not in > general [...] The general way would be to repeatedly Pull and Unpull patches in the temporary repo until every wanted constellation of patches is achieve and tagged. The --pull-to is just a way to select a bunch of patches. There are other ways, like --match 'date "before 2005"'. The --pull-to is, as you noted, mostly useful when the patches are stored in "order". > What I'd like to know: is there a general way to deliberately reorder > patches in some arbitrary darcs repo in a way that either guarantees that > they are in historical order or else fails? I can imagine to do this with a > script: extract info for all patches, sort by timestamp, then apply them in > this order to an empty repo, failing if there are any conflicts. The way you describe is the only way I know of. I used to sometimes want to bring my active patches to the end of the changes. When I update a working repo with patches from the master repo, the new patches get in at the end of the changes, and Changes --last no longer shows the patches I'm working on. But then I found out Push --dry-run is a much better way to see what I have. > Would it make sense to implement such a procedure as a darcs command? Or as > an external script? Anyone maybe already done this? Reordering patches is usually time-consuming, and in the presence of mergers it can take a very long time, so it's not a good idea to reorder patches unless you have to. If you want to have patches ordered by date, you probably just haven't got used to darcs yet, or the revision control you are doing is not suited for darcs. Or I'm completely dead wrong, which is always a valid option. :-) -- Tommy Pettersson <[EMAIL PROTECTED]> _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
