On Wed, 05 Dec 2007, Mark Phippard wrote:
...
> > > But, I thought in the second case (coming back to trunk) we would be
> > > converting this into a 2-URL merge internally? I thought this was
> > > essentially just syntactic sugar? My point is that the properly
> > > crafted 2-URL merge would work fine in the situation I outlined, so as
> > > long as we can programmatically determine the right options, we could
> > > do the same. I thought that is basically what your proposal was also
> > > saying? I just want to relax (slightly) the WC revision requirement
> > > so that it is a little easier for someone to take advantage of this.
...
> Your original spec said you would take the REV
> of the WC and then make go to the URL, get is mergeinfo and make sure
> it had been synched up to that revision. It seems like you could
> easily turn this around. Go to the mergeinfo, find out what revision
> it had been synched to, and then just make sure the WC was at least at
> that revision.
I've added a very basic implementation of that (which probably doesn't
handle renames).
> I wonder once you go through this cycle once:
>
> 1) Create feature branch
> 2) Changes on feature branch
> 3) Synch with trunk
> 4) More change on feature branch
> 5) Synch with trunk
> 6) Merge back to trunk
>
> Now, suppose you want to make more changes on feature branch. Can the
> cycle just repeat? Does the user need to know that they should
> probably delete branch + recreate it?
Can't the feature branch can be reused without deletion?
- application/pgp-signature attachment: stored
Received on Thu Dec 6 23:36:43 2007