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

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

Re: [Gnu-arch-users] names -> tagline method transition


From: Tom Lord
Subject: Re: [Gnu-arch-users] names -> tagline method transition
Date: Wed, 28 Jan 2004 08:08:30 -0800 (PST)

    > From: =?iso-8859-1?q?Michael_Teichgr=E4ber?= <address@hidden>

    > when turning an old project from id-tagging-method `names' to
    > `tagline' I wondered if it would be possible to minimize the changes
    > caused by this action.

    > As ids for files in a `names' tree are composed by

    >    str_alloc_cat (limits, "?", as_file)

    > and ids for untagged files in a `tagline' tree by

    >    str_alloc_cat (limits, "?_", as_file)

    > the transition will recognize most files as deleted+added. Would it
    > have drawbacks to treat ids beginning with "?_" and "?" as the same
    > when calculating changes?

It wouldn't be an upwards compatible change.

What would be upward compatible and also more general is to support
(yet another) tagline syntax and an alternative format for the
contents of .id files, in both cases permitting (in essense) the exact
file tag to be specified literally.

That would let you convert from anything to explicit, implicit, or
tagline.  There is, of course, no general way possible to convert from
other things to names.


    > A different thing is that files within the {arch} directory get
    > "?..."-style ids in a `names' tree, while they are assigned
    > "A_..."-style ids in a `tagline' tree. This causes files within
    > {arch} get deleted+added as well, though they always stay the
    > same.

Yeah, sorry about that.  The only that comes to mind is an
=tagging-method directive that let's you explicitly choose one of the
two styles.


    > By moving the `if (method == ftag_names)' block in inv-ids.c behind
    > the `is_at_or_underneath_archdir (as_file)' test, it is possible to
    > use "A_..." ids in `names' trees to. Users working on `names' trees
    > would have to recreate the corresponding library (because of index
    > differences) and for some edge-cases perhaps face problems when
    > applying certain changesets.

Right, which is why a new directive is preferable.   If you have a
names tree and want, say, a tagline tree, you would:

  1) explicitly id everything outside of arch with a literal
     tag equal to its current names tag

  2) add the name-ids-for-arch-files directive to =tagging-method

  3) change =tagging-method from names to tagline

and then, at your leisure, move the explicit ids into embedded literal
ids.


    > With this change and a hack for the first case above I was able to
    > narrow the list of changed files in a names->tagline transition to
    > "{arch}/=tagging-method". Would such a change in tla be worth the
    > effort, or rather not, since such transitions will rarely occur?

My feeling has long been that such changes would be rare and that,
worse:

a) the inventory stuff is already too hairy

b) changes like this require very careful testing since they can
   break everything pretty soundly

New users often ask for this feature.  They get started quickly by
using names or explicit method, then want to transition, and get
annoyed at the discontinuity.  I don't think that that's a good reason
to add the feature.

A recent trend is more people looking into tracking external projects
that aren't natively handled in arch.   Would this feature help a lot
with that?   I think it might.   Not so much for
names->{explicit,tagline} but for (file-by-file) explicit->embedded.

In other words: start tracking some upstream project.  Use the
`tagline' method but actually assign ids to file by using `tla add'.

Then, should the upstream project become more "arch friendly",
embedded tags can be added to its files without changing their
identity.

Note that this second scenario -- the upstream tracking one -- would
not need the "name-ids-for-arch-files" directive; just a way to embed
literal tags in files.

-t





reply via email to

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