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

[John Arbash Meinel]

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

> Hello GNU ARCH users!
...

> Only the one problem I see now. For example next situation:
> 1) Developer merges changes from local to main archive;
>   (and arch generate the new patch-log)
> 2) All another developers don't change this archive;
> 3) At night cron run job for automerge, and this patch-log
>   (as a new changeset) will be merged and commited to
>   local archive.
> 4) Local archive again has changes (last commited patch-log)
>   and developer go to point 1)
>
> Is exist right method to handle this situation?
> Or may be I am use broken ARCH usage schema?
>
>
>
> Thanks in advance!
>
> ---
> WBR, Popkov Alexander.
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.

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.

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?

John
=:->

signature.asc
Description: OpenPGP digital signature