[darcs-users] making add/remove file commute with content change

[Petr Rockai]

Hi,

Ben Franksen <ben.franksen at online.de> writes:
> *darcs should allow to record changes to the content of a file that has been
> removed (or wasn't even added in the first place)*
[snip]
> What do you think?

Well, I think this is a good idea. I think I may have already
mentioned this somewhere, but what I do to work around the problem: I
create an _attic directory, and instead of any darcs rm i do darcs mv
underneath _attic. This makes "removal" commutable with changes and
moves, and makes resurrection again easy and commutable. So what you
basically ask for is that add/remove are implemented by disabling and
enabling the file in the tree, right?

One problem I can see with that is addressing the "removed" (or
non-"added") files. You still need some sort of name for the file,
when it "does not exist" in the repository. Further ideas? 

One would be, that you could establish a git-like content addressing
scheme, and hunks would refer to content-hashes instead of filenames;
commutation should be implementable in that world as well (each
commute would also involve something akin to current rename-hunk
commutes). Sounds like a deep and incompatible change in the
implementation. In this scheme, the "tree" would then just contain
pointers to the "blobs". (Well, yes, I have been thinking a little on
how to use a git-like structure for a sort of pristine cache
efficiently, too.)

But there are probably much easier ways to implement this, too...

Yours,
    Peter.

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation