[darcs-users] Looks nice. Noob questions.
a_griesser at acm.org
Wed Jan 21 00:03:23 UTC 2004
On Mon, 19 Jan 2004 12:34:47 -0500, "David Roundy"
<droundy at abridgegame.org> said:
> > 0. The repository is in synch with the working directory.
> > 1. I make changes to the working directory.
> > 2. I find the differences between the repo and work dir (whatsnew
> > 3. I schedule changes to the repo (requiring explit scheduling avoids
> > commiting changes accidentally made to the work dir)
> I'm not clear as to what you mean by "schedule changes"... that is, how
> step three is distinct from step four.
> > 4. I commit the scheduled changes
> > 5. Make any necessary changes to work dir (if necessary recreate it) so
> > that I am now back in state 0.
Perhaps I am not "thinking darcs". Step 3 defines a "unit of work":
changes to the repo that are related to each other, and which should
be accepted into the repo or rolled back as if they were one atomic
operation. Step 4 tells the repo to "go ahead and make changes
scheduled in step 3". Step 3 involves "darcs add" and "darcs remove"
(ideally without automatic detection of files to remove), while 4
is "darcs record".
> The only time I do your 5. is when I've made temporary changes I don't
> want to keep (such as adding debug printfs), in which case I'll generally use
> a darcs revert to undo them.
Yes. Same here.
I guess we are using it the same way, except that you want to see a
detailed explanation of pending changes instead of a summary, and
prefer to let the repository deduce which files to delete.
Perhaps I prefer "whatsnew --summary" because I use record too
infrequently, and end up with a lots of changes that would melt
my mind if I tried to understand "whatsnew" without "--summary".
Perhaps you use "darcs tag" the way I use "darcs record".
> symmetric. But really, the fact is that additions and removals are *not*
> symmetric. In the case of a removal, darcs knows that it should be
> keeping track of changes to that file (because you already told it to),
> while in the case of a new file that shows up in the working directory,
> there is no way to know if you want it in the repo.
Good point. I admit I want the computer to automate things for me.
I should probably rely on automated detection of removed files,
instead of wanting to explicitly tell darcs. No doubt darcs makes
it easier to back out an accidental deletion anyway than "brand X".
Ok, I'm convinced, I will try it a while.
More information about the darcs-users