David Roundy writes: > Given our previous troubles, I can't help but wonder if this removal is > worthwhile. It's probably safe, but that's what I thought about your last > patch. And the absolute safest approach is to not change how we parse > dates, which is the conservative approach I lean towards, since we have > absolutely no way to know for certain what's present in older > repositories.
It's always a bad idea to break such a promise; as you say you just can't know. With something like dates that humans manipulate a lot, you might want to keep the code around to help with extended features in the future. Why not keep an array of date parsers, and if you like, issue warnings for the deprecated ones? A wild thought: It might be interesting to have a general translation utility available for "fixing" such issues when cloning repositories, although how you would preserve the name I'm not sure. (The changed patches would have to have new names, I'm pretty sure, but you'd want to be able to refer to the originals and keep them around, I think.) Another application would be if you have a repo created by 1. copy Darcs workspace from a repo to "just a tree" 2. import that tree to another version control system (aVCS) 3. tailor aVCS to new Darcs repo you could update the dependencies to be those of the originally copied repo. This is a use case just described on the list (or maybe that was Darcs Users). _______________________________________________ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
