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

[John Arbash Meinel]

Don't forget to reply to list, instead of just me. :)

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

> 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?
You're right, with as big of an installation that you have, pqm makes
the most sense.

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

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

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.

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

> Sorry for my bad English.
> Thanks for discussion!
>
> ---
> WBR, Alexander Popkov.
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.

John
=:->

signature.asc
Description: OpenPGP digital signature