[darcs-users] darcs annotate format obscures the code

Michael Conrad conradme at email.uc.edu
Mon Mar 21 13:14:09 UTC 2005


Ivan Stankovic wrote:
>b) why are the numbers tag-based? I'd find it more natural if they didn't.
>   Also, when I say e.g. "Stable-0.1.2" does it mean "tag Stable-0.1.2" or
>   "the patch number 2 after the Stable-0.1 tag"? By not using tag-based
>   numbers we could avoid this and the problem of unpulling a tag (which
>   you wrote about in your mail).

I just figured it'd fit right in with the usual build numbers that people
use.  I suppose it would be equally easy to just number them continuously,
and if someone wanted a build-number to attach to their tag name darcs could
scan for the number where the last tag was applied and subtract that from
the current number.

However, it might be nice to have a way to reset the numbers (for
long-running projects) and doing it automatically on new tags seems like a
really convenient way to do it.

Ralph Corderoy wrote:
> Michael Conrad wrote:
> >
http://www.abridgegame.org/pipermail/darcs-users/2005-February/005455.html
> >
> > Basically, I think we CAN get a version number for each revision, and
> > rather easily, too.  It would be the perfect thing to display on an
> > annotation.  A person could then cross-reference the version number
> > using "darcs query version <x>", or we could even write them in the
> > 'changes' output for grep to find.
>
> Nice post.  I think a repo-private integer for each `change' is do-able
> as you say.  I'm not sure it's worth restarting at 1 on a tag, or
> confusing it with getting `x.y.z' version numbers.  If numbers are ever
> deleted, e.g. 42 is no longer used, then an explicit command to `pack'
> the numbers back down, i.e. make then contiguous from 1, would be
> useful.

Actually, the way I was proposing it, the numbers would never get reused.
The reason is so that in the other use case (of attaching versions to
released builds) if someone calls up with a bug in version x.y.z it will
correspond to the exact repo-state that generated it, even if this repo
state is no longer reachable.

For example, suppose I add a patch:
  195 apply "Patch Blah...."
and then release the code, and later:
  207 remove "Patch Blah...."

and then someone reports a bug in "Version Main-1.0.3.195".  I then tell
darcs to go back to version 195 and darcs fails with "Can't go pack beyond
version 207: missing patch".  So, then I can look into the history file to
see what patch I killed which prevents me from going back.  If I'm lucky,
I'll still have that patch somewhere so that I can recreate the copy that
the user is using.

Anyway, while this is an example of "things not working", I hope it shows
how renumbering would make things a bit worse.

Ivan Stankovic wrote:
> a) what would darcs do if, using the above example, I say
>    'darcs diff -u --patch-number 3'? Would I get the inverse of "Patch
Bar..."
>    or something else? Similar question for "patch number 5".
>    IMHO, it's confusing to have numbers refering to different things; as
you
>    can see, I already began calling these numbers "patch numbers" :)

Well... in the Darcs I'm dreaming of, there would be a "dead patch holding
area" which would have all the patches which had been removed, and darcs
would have a "rollback" command which could temporarily move aside patches
to essentially roll the repo back in time.  If that were the case, then all
the commands that deal with repo versions would roll the repo back to
version x.y.z (or make a cheap branch and roll back the branch) and then
perform whatever comparison you had asked for.

That is asking rather a lot though.  I'd just be happy for now if I could
get a sane version number ;-)

-Mike





More information about the darcs-users mailing list