O. Now we're getting into the technical details and work flow, which seems to
have uncovered a lack of thought about this idea of mine!
OK... so.. Whilst I have been tinkering, created branches made some changes
merged back and forth, then decided that the final thing would be to try the
reintegrate. So updated branch to match trunk switched to trunk and
reintegrated.
Checked the changes.. and commited them. In the message log there is an icon
which signifies that a merge activity has taken place, which would suggest
that (T)SVN (I dont knkow if we are talking Tortoise or SVN functionality
now!) knows from where the information has been merged from (which branch).
At this point I think it would be safe to have the option of deleting the
now (in this case) obsolete branch.
Now I suppose what I have started thinking about now is what if some of the
changes are NOT commited at this point? Or what if I dont commit the merger
straight away and make additional changes to the trunk?
My initial answer to that would be: Still allow the option to delete the
branch even if only a 'partial commit' is carried out. Working on the theory
that a) If you have everything you want out of the branch and it is
obsolete, it can still be deleted. b) If you have everything you want out of
the branch, but you need to keep the stuff you have not integrated, then you
dont have to select to delete the branch. This would be better demonstrated
when the revision graph function is updated (It would show where and when
the reintegration was made, and therefore any further modifications
afterwards.).
As for the additional changes to the trunk before commiting.. Surely (T)SVN
knows when a merger is being commited as some sort of 'record' exists to say
where/how a change was made? So this wouldn't be an issue.
I can see now that you wouldn't want to delete the branch before the merger
was commited. That makes perfect sense. But given that you never remove
anything completely from a repository, I still think there is scope to have
the optional delete function available when this type of merger is commited.
Is that a better description, or are there more things I need to consider?
Adam.
Dave Lawrence wrote:
>
> adstar wrote:
>> Cool. Makes sense. How about then, the option to delete a reintegrated
>> branch? It's availability could be 'permission' based, and would be
>> 'deselected' as default so you have to willingly delete the branch.
>>
>> I know we are getting into the realms of personal requirements, but it
>> seems
>> to me a logical extrapolation of the reintegrate function, which
>> basically
>> moves all the branch into the trunk.. so why keep the branch?
>>
>> I know there is the possability of it being kept as a 'tag', or fixed
>> point
>> reference, hence the delete function being optional.
>>
>> Anyway. Just a thought as I am on something of a role!
>
> How would that work? Are you suggesting that the branch would be
> deleted immediately the merge had finished? ie before the merge had
> been committed back to trunk?
>
> And you couldn't schedule the branch deletion into the working copy
> either, unless the branch and the trunk were both part of the same huge
> (or sparse) working copy, which wouldn't normally be the case.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
>
>
>
--
View this message in context: http://www.nabble.com/Reintegration-Merging---revision-graph-tp20498286p20499300.html
Sent from the tortoisesvn - users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-11-14 13:10:34 CET