[Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)

[Petr Rockai]

Hi,

Grant Husbands <darcsusers at 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.