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

[Попков Александр]

John Arbash Meinel wrote:

>>>Maybe I'm wrong. I can see that there might be some advantage to always
>>>being up-to-date with the mainline tree, even if you have local changes
>>>for your branch. But I also know that if someone merges a change that
>>>breaks my branch into mainline, (say they rename a function that I am
>>>using). When I update, everything will be broken, even though the merge
>>>was successful. And *then* I have to track down what changed, rather
>>>than being aware of it at the time I merged it in.

>>For handle this situation we just do testing devel branches before 
>>>>maintainer merge changes to stable. I am adding postcommit hook's to
>>>arch-pqm, which updates changed projects in its "test locations".

>So what branches are you doing automatic merges? Isn't that the devel
>branches?

I am having three main wrappers
1) vcs-commit
     do tla commit to devel branch in local developer archive, this
     wrapper for avoid empty comments and empty commits
    (do 'tla changes -q' before commit and stop if no changes made)
2) vcs-merge
     make request to arch-pqm for merge changes from devel branch
     in local developer archive to devel branch in main (centre) archive.
3) vcs-release
     make request to arch-pqm for merge changes from devel branch
     in main archive to stable branch in main archive. This can do
     only project maintainer(s).
     (stable branch placed only in main archive and the unique way
      for update it - this wrapper, this avoid conflicts)

Automerging from main-devel to local-devel I want integrate into
second wrapper (vcs-merge). No another automerging in own schema.

>Even so, you have an interesting idea to automatically update users
>trees with stable updates.

Thanks ;)

>However, I would hesitate to change working directories. Can you have
>the script just update their branch. It could do a local checkout, and
>star-merge, then commit if everything succeeds. When the user goes to
>commit, they will be informed that their tree is out of date, and they
>need to do an update first.

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 ;(

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?
    
>
...[skipped]...
>
>>Yes, this sounds good, but major portion of our developers haven't any RCS
>>using experience, and I have an small idea:
>>
>>- write commit wrapper, which do
>>   a) 'tla star-merge $mainline'
>>   b) stop if any conflicts appears
>>   c) 'tla commit ...'
>>
>>It seems to me that this wrapper be fine for arch (and others RCS in >>whole) 
>>beginners. Of course I am will describe these wrapper actions in 
>>>>corporative technical documentation, for don't mislead our developers.
>>
>>What do you think about this idea?

>The biggest downside is that you start mixing a star-merge into the
>actual change. Which means if you want to merge that specific patch
>later, it also includes the other changes. Which you probably don't want.

>I would tend to suggest something more like:
>a) tla undo
>b) tla star-merge $mainline
>c) if changes> tla commit -s "mainline sync"
>d) tla redo
>e) if no errors> tla commit $*

>The biggest problem is that it is really hard to tease apart a
>star-merge in a working tree if you have other changes.

>I think a more recommended change would be:
>a) tla commit
>b) tla star-merge $mainline
>c) tla changes

>That way the commit succeeds with the changes the developer intended,
>but as soon as it is done they are informed if there are any problems
>against the stable mainline. You might even add a
>d) if no errors tla commit -s "merge from mainline"

>I think my favorite is to have a script commit merges into the archive,
>but not touch the working directory. Maybe I'm a little protective, but
>the feeling that my working dir is changing from underneath me isn't
>very comfortable.

I am not having chance for "tla commit" to main (centre) archive in my schema. 
Only star-merge:

+---------------[ 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?

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.