[darcs-users] on the subject of better names...

[Adam Megacz]

I know this is an ancient thread, but I wanted to read up on the darcs
documentation before posting, and it took me a while to find time to
do that...


David Roundy <droundy at abridgegame.org> writes:
>> Is there any chance we could merge unrecord and unpull into
>> deletepatch or destroypatch or something like that?
>>
>> My primary gripe is that patches can come from things other than
>> pulling and recording (rollback is the most confusing example).
>> There's no "unrollback" command, but since you didn't "pull" or
>> "record" the rollback patch, people wouldn't think that "unpull" is
>> the right way to undo a rollback.

> Well, unpull isn't the right way to undo a rollback, unless you have also
> performed a revert after the rollback and want to undo both actions, or if
> you got the rollback via a pull.

This still has me really, really confused.

As I understand it, the darcs world consists of:

  - a pile of patches
  - a copy of the tree at the time of the last record (_darcs/current)
  - the working copy

Now, if I understand correctly, 'darcs rollback' adds the inverse
patch to _darcs/patches and applies it to _darcs/current and the
working directory as well, right?



> I like the names unrecord and unpull, because they suggest the times when
> you could use them safely, which means that newbies are hopefully less
> likely to accidentally shoot themselves in the foot with them.

Eehhh... I dunno.  If you want to stop people from shooting themselves
in the foot, a simple "this is irreversible, are you sure?" will work.
The thing is that with version control, trust is a big issue.  People
want to know how stuff works before they trust their code to it.  I
think CVS is popular because it's so simple that everybody understands
what it's doing when they type a command (with the exception of
branches, which most people just don't use).

I guess it might help people feel more comfortable if (perhaps in
addition to the existing descriptions) there was a simple model of
"these are the data structures darcs keeps on the disk" and then
phrase each command in terms of what it does to those strucures.  Not
necessarily why it does what it does (which the theory of patches
explains).


>> I guess you could have something like
>> 
>>    destroypatch [-k] [-m patchname]
>> 
>> where -k would keep the changes in the working copy (like unrecord)
>> and without -k the working copy would be rolled back as well (unpull).

> I don't like the idea making unrecord and unpull too similar.  Unrecord is
> safe, and unrecord is dangerous,

I think you mean "rollback is safe".... again, if I understand
correctly, 'unrecord' destroys the distinction between the last
recorded patch and whatever changes you've made since then (and hence
is unsafe), and unpull is even worse as it not only removes the record
(in _darcs/patches) but the 

I'm not advocating a change to rollback...

Not to belabor the point, but perhaps unsafe stuff should have an evil
word in the name, like "destroy" or "obliterate" or "kill" or perhaps
even "maim". ;) "Un" doesn't really sound dangerous to me, especially
in the context of version control.  The "undo" option on the edit menu
of just about every windows/mac app is "redo-able"...


> them be a command line flag seems unwise.  At the very minimum, the default
> would be to unrecord and a flag would be needed to make it an unpull, since
> at least that way the safe behavior is default.

Hey now that's a good idea, since unrecord is actually a subset of
unpull (unpull is effectively unrecord+revert, right?  assuming no
unrecorded patches in current, of course)


> But really, I don't think unrecord and unpull should have similar names at
> all.  Unrecord is a safe tool that you can use regularly without worrying
> about losing any of your data.

> Unpull can only be used "safely" on patches that you previously
> pulled, or on rollback patches that have their corresponding changes
> reverted.

Right, but there are a lot of times that I really want to destroy a
patch.  And it took me a half hour to figure out how -- since I had
never pulled the patch, I thought "unpull" wouldn't have anything to
do with it!


> In that respect, revert is already redundant.  But it is usefully
> redundant.  Adding extra complexity to the revert process seems more likely
> to cause errors to be made.  There is also the fact that the revert patch
> can be undone, while unpull can't.

"revert patch"?  I thought that revert doesn't add anything to
_darcs/patches.  Am I mistaken?


> Of course, undestroypatch functionality

Er, no...  I was advocating destroyXXXX to be only for irreversible
operations, so "undestroying" a patch would be impossible (like
ununpull)...

  - a