On Wednesday, 16 November 2005 at 08:52, Lele Gaifax wrote: > Thanks a lot, Brendan! Your flood of patches made me happy, and this > is something new, in these days.
Thanks for tailor! And hacking on it can sometimes be a nice distraction :) > I will try to drive the 1.0 release, now that almost all backends > support source and target functionalities, and will try to bootstrap seems like some of the engines could use more testing. I may have an unusual environment (OS X/fink), but several of the source engines are having trouble here (I think I fixed bzr, but it may only work here :)). Right now I'm dealing with darcs, where I've noticed a couple of things: * the xml output (darcs 1.0.4) produces dates of the Sun Oct 20 20:10:05 EDT 2002 variety rather than 20021020201005 as the changelog parser expects * empty changelogs crash python (the test if last: never fails because last is a generator, but last.next() will raise StopIteration) These first two I have patches for. But more seriously: * darcs pull --dry-run produces times in the local TZ (UTC if that's what's set, of course) but the hash of the patch uses the time in the original commiter's TZ. So unless TZ happens to be the same, the hash tailor calculates doesn't match. Commenting out the bit that creates changeset.darcs_hash (so tailor falls back to fetching patches by author/date/name) seems to resolve the problem for me, but I'm not sure that's the way to go... > the VersionTwo milestone on the tailor trac. Of course, you all are > invited to expose your own wishes on that, here are my first idea: > > * better separation of "low level" stuff (ie, move such methods on the > Repository class) > > * several people asked about a "VC-neutral" representation of patches: > I'd really like to propose such format (I'm biased toward YAML) I'm not sure what this means? It seems like, for example, darcs' replace patch would be impossible to represent in a way that CVS could understand. Maybe this patch format always includes a unidiff, but also special annotations? I think bzr uses a format like this... > * better handling of branches: at the very least, I'd like to be able > to tailorize a new branch, having already a tailorized trunk of the > same repo * Different repositories have different capabilities (eg tags, versioned tags, retroactive tags, git's distinction between author and committer, darcs' replace patch). It'd be nice to have a changeset object that could accommodate any of these while still allowing less capable targets to fall back. _______________________________________________ Tailor mailing list [email protected] http://lists.zooko.com/mailman/listinfo/tailor
