Hi, Grant Husbands <darcsus...@grant.x43.net> writes: > 1. When you unpull old patches or reorder patches, Darcs alters > existing patch files. This will break other branches that share the > same files. Not true, since the filenames are fully determined by the file content. Hashed repositories will just create a new file for the modified patch.
> 2. Similarly, when you pull patches in different contexts, you end up > with slightly-different patches with the same name. Same as above. > 3. With enough unpulling on one branch, you probably break the root > for another branch, by removing the shared inventory behind the head. This can be addressed by a GC policy. It's probably not feasible with current darcs, but keeping around "root" pointers to inventories is not much different from keeping extra roots for pristine. > 4. Pushing and pulling between branches would be very hard to > implement without heavy Darcs involvement. The method in the proposal > will not work, as Darcs in either branch can't necessarily understand > the context produced by the other branch. I'm not sure I follow your argument here. The proposed thing is the exact mechanism behind "darcs push" -- grab context of remote repository, commute patches you have to a common point and create a bundle, then use apply on that bundle... > 5. Updating the working copy correctly for many branch operations > entails knowing how to handle all of the darcs patches that are > different between the branches. Even if you force the user to have no > working copy changes, what about the unversioned extra files, > especially in renamed folders? The "switch" problem wouldn't be any easier whether implemented inside or outside of darcs. This basically entails unapplying patches up to a common point and then applying missing ones. This may or may not work, depending on how much changed the working copy is. I presume we would abort without doing any changes may this break. > 6. As noted in the proposal, it's not known how to make it play nicely > with lazy fetching. I don't expect any problems here. I also don't see the original note? > 7. The branch-knowledge synchronisation requires almost as much > knowledge about how to handle remote Darcs repos as Darcs has. This is likely true. Yours, Petr. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe