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

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

John Arbash Meinel wrote:

> So, the problem with this scheme, is that you are saying "Everybody gets
> Their own archive", but then you turn around and say, "But everyone has
> to stay perfectly synchronized."
> At that point, you really should do a centralized model, since everyone
> is staying up-to-date all the time anyway. I know that as a developer, I
> wouldn't really be happy having my sources update behind my back.
> If we are all sharing the same repository, at least there is the
> expectation that we should do an update before a commit.

We having centralizing model based on arch-pqm, which maintain main archives. 
So, users, as I said - have local self owned archives.
We don't want to dance with access rights and make one centralized
archive with r/w access from all developers, because:

- we have a lot of projects (about 30)
- we have a lot of developers (about 50)
- we need a place, which always contain _stable_ releases
  (just having two branch for each project: devel and stable)
- we need to distinguish access rights to stable branches, only
  this particular project maintainer(s) must can do merge from
  devel to stable branch.
  (using precommit hook from arch-pqm to check this)
- we need for simple operations "edit maintainers list", "edit project
  list", etc.
  (store 'project -> maintainers' info in database, write small and simple
   web interface for edit info in this database)

I can be mistaken, but think this not very easy if out of arch-pqm based model?

> 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".

> My personal feeling is that you should advise your developers to keep 2
> working trees. 1 that is the latest committed patch, and the other is
> where they actually do development.

> Then every morning, they "tla update" the latest dir (because they
> committed from the other one). And then they run "tla star-merge
> $mainline". They can review what changed, and see if they want to add it
> in to their work, or if they need to wait.
> And then they can "tla commit"/"tla undo".
> If they undo, they should at least be thinking about how to work with
> the latest changes to mainline.

> Does this make sense?

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?

Sorry for my bad English.
Thanks for discussion!

---
WBR, Alexander Popkov.