Re: [Gnu-arch-users] tla star-merge in cycle, how to work around?

[John Arbash Meinel]

Попков Александр wrote:

> John Arbash Meinel wrote:
...

> This is a great idea! Big thanks!
> I think this clearer then star-merge into current working dir of project.
> But problem remain: before each user commit it tree will be out of date,
> because each star-merge + commit generates new patch ;(
Well yes and no. The tree is only out of date when there was a new
stable update. But this is the case anyway. If you want the developer to
merge in the latest stable before they get a chance to commit their
changeset, their tree is effectively out of date.

> 1) Developer commit changes to own local archive
> 2) Developer merge changes from own local archive to main archive.
>   This operation generate new patch-XXX in main archive
> 3) Next time developer make and commit changes in own local archive,
>   his run vcs-merge:
>     automerge add address@hidden/project--devel--0--patch-XXX to
>     address@hidden/project--devel--0 and local working dir of
>     this developer is out of dated (it not contain patch-log
>     about previous merging, but contain all merge changes!)
>   Developer must do 'tla update', ..., 'tla commit'...
> 4) and vsc-merge... goto 2.
>
> I am don't know what do with this "cycling patch-log-message-about-merge".
> May be this is normal situation?
You could always have your vsc-merge script check to see if the only
change is a patch-log, and if so, undo the change. You are right, if you
have 2 trees star-merging eachother, they continually spiral, since each
time adds a new patch-log saying that it was merged against the other tree.

>
...

> I am not having chance for "tla commit" to main (centre) archive in my schema. 
> Only star-merge:
Just to make sure that you understand, star-merge just updates the local
working directory. You still have to do a "tla commit" to push the merge
into the archive. But I think you are saying that you won't allow
development changes directly committed into the main archive.

> +---------------[ MAIN (CENTRE) ARCHIVE ]-----------------+
> |                                                         |
> | +---------------+                     +--------------+  |
> | | STABLE BRANCH | <---(star-merge)--- | DEVEL-BRANCH | <------+
> | +---------------+     (vcs-release)   +--------------+  |     |
> |                                                         |     |
> +---------------------------------------------------------+     |
>                                                             (star-merge)
>                                                             (vcs-merge)
>                                                             (PROBLEM-POINT)
> +---------------[ LOCAL DEVELOPER1 ARCHIVE ]--------------+     |
> |+---------------[ LOCAL DEVELOPER2 ARCHIVE ]--------------+    |
> ||+---------------[ LOCAL DEVELOPER3 ARCHIVE ]--------------+   |
> |||                                                         |   |
> ||| +--------------+                                        |   |
> ||| | DEVEL-BRANCH | -------------------------------------------+
> +|| +--------------+                                        |
> +|      ^                                                  |
>  +------|--------------------------------------------------+
>         |
>      (commit)
>      (vcs-commit)
>         |
> +--------|-------[ LOCAL DEVELOPER1 WORKDIR ]-------------+
> |+-------|--------[ LOCAL DEVELOPER2 WORKDIR ]-------------+
> ||+------|---------[ LOCAL DEVELOPER3 WORKDIR ]-------------+
> |||      |                                                  |
> ||| +----------------------+                                |
> ||| | DEVEL-BRANCH WORKDIR |                                |
> +|| +----------------------+                                |
> +|                                                         |
>  +---------------------------------------------------------+
>
> What _right_ solution for back-star-merge (from address@hidden/devel to
> address@hidden/devel) in PROBLEM-POINT in this schema?
Well, I would probably say *don't*. You can back-star-merge from
address@hidden/stable, but you probably don't want everything kept up to
date with address@hidden/devel. Because until the maintainer has decided
something is stable, you probably don't want to force the changes on
everyone else.

I would also say that the PROBLEM-POINT should be taken care of by the
pqm. The pqm can then inform people when changes have been made that
they should be aware of.

> In other words "how to true sync user local archives from mains?"
>
> I am understand what this actions must be integrated into my 'vcs-merge' 
> wrapper, but not understand clearly what this actions must do.
>
> I am confused ;( My solution generate a lot of unnecessary patches in projects 
> ;(
>
> Thanks in advance!
>
> P.S. Thanks for read my knotty problem to end...
>
> ---
> WBR, Alexander Popkov.
I will try to spell out the steps I think:

  1. Developer commits changes to a personal devel archive
  2. The devel pqm is informed there is a new patch, and tries to merge
     it against the main devel archive.
  3. If successful, new patch is committed to main devel. Email is
     generated to all relevant developers.
  4. When the maintainer reviews the latest submissions and is happy,
     he merges them into mainline stable (and commits).
  5. On commit to the mainline stable, all personal devel archives are
     updated with the stable patch.
  6. Developers are encouraged that if they see something they like
     from the email in step 3 that they can manually pull from main devel.

The problem I see with this setup, is that arch doesn't handle merging
between 3-levels of trees very well. I *think* star-merge --three-way
would do what you want. Since it can ignore changes that are already
present.

John
=:->

signature.asc
Description: OpenPGP digital signature