Hi,
Grant Husbands
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.