[Gnu-arch-users] Re: Cascading patchlogs with star-merge

[Shawn Samuel]

Merging by hand is useful where you're merging between different
development streams. In any environment where you have multiple
mainline archives that are logically federated, and all commits 
are always going to percolate up the tree to the master archive, 
automated merging is often going to be a requirement. 

I've just started using Arch for personal projects, but already I 
can easily see a number of reasons why Arch would've been great at my
last shop, where we used ClearCase, and part of what it did that 
most SCM's don't (and we needed) is to enable exactly the situation
I described above. In this case, I would have setup an auto-merge
between archives, but you wouldn't want commits to result when
your merge process ran but there were no actual changes to be committed. 

This functionality would be nice to have as part of tla commit as an
option, but I don't see it as a requirement for the arch core. It would 
be just as well to have as part of tla-tools or somesuch, as a wrapper 
to tla commit that would fail whenever there were no actual changes to 
be committed. Either way, I think it is functionality that would be a
useful addition to arch.

shawn

> Date: Sun, 21 Mar 2004 13:30:15 -0500
> From: James Blackwell <address@hidden>
> Subject: Re: [Gnu-arch-users] Cascading patchlogs with star-merge
> To: address@hidden
> Message-ID: <address@hidden>
> 
> >   Commit patch-N in archive 1
> >   star-merge from archive 1 into archive 2, then commit, creating patch-M 
> > there
> >   star-merge from archive 2 into archive 1, commit creating patch-N+1 there
> >   star-merge from archive 1 into archive 2, creating patch-M+1
> >   ... etc
> >
> > This can go on forever, and the only things getting added to the working
> > copies each time are patch logs.  I was looking to automate the sharing
> > of patches like this, but found that it never stopped.
> 
> Its up to you and him to notice that the only thing that changed was
> patch logs. If you star merge somebody and the only change you see is
> patchlogs, then why would you commit that to your tree?
> 
> 
> 
> -- 
> James Blackwell      Using I.T. to bring more             570-407-0488
> Owner, Inframix      business to your business     http://inframix.com
> 
> GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sun, 21 Mar 2004 18:21:34 +0000
> From: Stig Brautaset <address@hidden>
> Subject: [Gnu-arch-users] Re: Cascading patchlogs with star-merge
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi Russell,
> 
> On Mar 22 2004, Russell wrote:
> >   Commit patch-N in archive 1
> >   star-merge from archive 1 into archive 2, then commit, creating patch-M 
> > there
> >   star-merge from archive 2 into archive 1, commit creating patch-N+1 there
> >   star-merge from archive 1 into archive 2, creating patch-M+1
> >   ... etc
> > 
> > This can go on forever, and the only things getting added to the working
> > copies each time are patch logs.  
> ...
> > How do people handle this in practice?
> 
> Personally, I like to do merges manually.
> 
> I must admit I don't really understand why you want to automate this,
> but one way to do it, I guess, is to add a magic header to the patchlog
> when you do a star merge ("X-star-merge: REVISION" for example). Then,
> if there is only one patch missing from the other branch you test
> whether the magic header is present. If it is, you know that the
> changeset will bring in only patchlogs and skip the merge. 
> 
> Or something like that.
> 
> Stig
> -- 
> brautaset.org
>