On Thu, 15 Feb 2007 13:34:47 +0100, Goswin von Brederlow <[EMAIL PROTECTED]>
said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> On Thu, 01 Feb 2007 14:47:59 +0100, Goswin von Brederlow
>> <[EMAIL PROTECTED]> said:
>>> If you had true parallel revisions then there should be a way to
>>> edit both "branches" at the same time and check in changes to both
>>> at the same time.
>>
>> This is trivial using arch and bazaar-ng, and probably any other
>> modern distributed version control system. I can make
>> non-conflicting changes to multiple branches (think typo fixes),
>> and check them all in all at once.
>>
>> manoj
> That is not what I ment. You are taling about different changes for
> each branch while I mean identical changes to the common parts of
> both (all) branches.
Err, So I apply a change to say, branch--foo. The I go to
branch--bar, and I say:
tla replay branch--foo--revsion-x--patch-y;
and the same change is applied.
What if I had independently applied the same patch to both
working trees? I would commit the identical change, and use
tla sync-tree
to let arch know the changes had been made in both branches, and any
future merge should not try to redo the changes -- no matter which
direction the future merge was done from.
> What I have in mind is that you work on your local copy of the
> source and then "foo commit" your changes. That then checks that the
> changes apply to both branches and warns you about possible
> conflicts, for example "Change of src/foo.c creates conflict for
> branch feature2".
Err, that already happens, even with CVS. You edit your local
copy, checking in to CVS warns you about not up-to-datedness; cvs
update warns you of conflict.
Of course, in arch, conflicting changes in different branches
is often the very reason to have the branch in the first place, so it
is not really helpful to have warning emitted all over the
place. I'll still learn of the changes whenever I try to merge; in
which case I'll notice, and apply a sync-tree later to not redo the
same change twice, and move on.
This does require a certain discipline of single change per
commit, but that is good practice anyway.
> The same would hold for a patch set where each patch is stacked on
> top of all the others. If you edit the source at patchlevel 3 and
> then commit the changes it would automatically check that
> patchlevels 4, 5, 6, ... still apply without conflict.
I don't do stacked patches, (and this is one of the reasons);
I prefer pure feature branches and an integration branch; any
conflict would show up at merge into the integration branch; and can
be handled then.
The advantage is that the patchset for each feature gets fixed
automatically once you get your integration branch into good shape --
so I never really have to worry about gazillions of patches, just
make sure the integration branch compiles correctly; adjusting each
feature branch as needed (which, despite what it may sound like, is
really a simple operation in practice).
manoj
--
Proclaim liberty throughout the land until all the inhabitants
thereof. Leviticus 25:10
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
