gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Working out a branching scheme [was: tag --seal


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: Working out a branching scheme [was: tag --seal --fix]
Date: Sun, 4 Apr 2004 20:26:39 -0700 (PDT)

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:
    > > Holy Cow!  That's close to an idea that I think could be _really_
    > > sweet.  Are you sure this isn't what you meant?:

    > > Have annotation work on a particular version, possibly on a linear
    > > list of versions.  Make tool like `patch' but that updates an
    > > annotated file (it only has to work for known-to-be-exact patching).

    > I'm a bit lost about what this tool is for.

What people want is something that will let them look at "foo.c" and
see (something like:)

    int
    some_fn ()
    {
      static int x = 0;

    >>>>>> base-0  (address@hidden,  12-14-1981)
      return x;
    ------ patch-1  (address@hidden,  1-13-1982)
      return ++x;
    ------ patch-2  (address@hidden,  1-15-1982)
      return x++;
    >>>>>> 
    }
      

So, I'm saying, make a `patch' variation that will take this:

    int
    some_fn ()
    {
      static int x = 0;

    >>>>>> base-0  (address@hidden,  12-14-1981)
      return x;
    ------ patch-1  (address@hidden,  1-13-1982)
      return ++x;
    >>>>>> 
    }

plus the changeset for patch-2, and yield the first version.

Then, use arch to construct a parallel version.  This thing:

    > > Now, derive a new version from the one you want to annotate.   So:
    > > 
    > >         tla--devo--1.3          =>      Annotated-tla--devo--1.3
    > > 
    > > with a 1:1 mapping of revisions.

using normal `patch' in tla--devo--1.3 and `annotating-patch' in
Annotated-tla--devo--1.3.



    > I'm a bit out of my depth here, since I haven't used
    > annotations.  

I don't either.  I think they are mostly overrated.  But it is a very
common request.  I suspect people take to them when their trees get
very confused and they're trying to figure out what the hell happened.

I suppose it's also good for looking at some code snippet and asking
"who is the genius that wrote _this_ bit".

The above design sketch let's you do annotate queries just by checking
out the "Annotated-" tree and looking at directly.



    > Is it 
    > okay to require that annotations cannot be changed without committing a 
    > new revision to the source tree?  (1:1 will introduce that requirement.)

Yeah.   Annotations are just a fancy way to view history.


    > > You'd also need some fanciness to get the base-0 revision right.

    > If all of these revisions are tags, doesn't patch-N have the same 
    > problems as base-0?

The "Annotated-" revisions aren't tags.  They're separate from the
arch perspective (although have common patch logs).


    > > That'll roughly doubles the archive storage needed and puts more
    > > pressure on revlibs --- but that's _all_ it does.

    > Hmm.  I wasn't suggesting storing any data in the annotation tree (just 
    > metadata), so the archive storage should be considerably less than half 
    > of the source tree.  Maybe I'm not understanding you.

Clearer now?  Or not?

-t







reply via email to

[Prev in Thread] Current Thread [Next in Thread]