[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Reintegration/Merging - revision graph

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 14 Nov 2008 18:34:02 +0100

adstar wrote:
> 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.

That icon indicates not a merge but a copy operation. That can also be a
rename of a file, or a copy of a file. It does not mean that you've
merged or that you made a tag/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?

This is your personal use case. Implementing something like this in TSVN
is not a good idea. Just remove the branch manually.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net

Received on 2008-11-14 18:34:15 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.