Login | Register
My pages Projects Community openCollabNet

Discussions > users > Branch and Merge problem?

Project highlights: :. Download .: :. Support .: :. FAQ .: :. Translations .: :. Donate .: :. Report Bug .:

tortoisesvn
Discussion topic

Hide all messages in topic

All messages in topic

Re: Blame info unclear

Author simonlarge
Full name Simon Large
Date 2011-05-10 13:27:11 PDT
Message On 8 May 2011 07:17, Stefan Küng <tortoisesvn at gmail dot com> wrote:
> On 07.05.2011 22:50, Simon Large wrote:
>
>> OK I see the confusion now. If you select the 'Include merge info'
>> checkbox then you get the G line. If you don't check that box then you
>> don't get the merge info, but you still get 2 columns which are always
>> identical. I guess that is just a subversion 'feature'. Does the -g
>> option take more time when fetching the blame? If not, is there any
>> reason not to do it always?
>
> Ah, you mean you get two revision columns even if the merge info wasn't
> requested. That's a bug of course.
> Fixed in r21320.
>
> And yes: fetching the merge info for blaming can take a long time,
> that's why it's an option and off by default.

The nightly build is broken at the moment so I can't check this.

Simon

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

Re: Blame info unclear

Author steveking
Full name Stefan Küng
Date 2011-05-07 23:18:02 PDT
Message On 07.05.2011 22:50, Simon Large wrote:

> OK I see the confusion now. If you select the 'Include merge info'
> checkbox then you get the G line. If you don't check that box then you
> don't get the merge info, but you still get 2 columns which are always
> identical. I guess that is just a subversion 'feature'. Does the -g
> option take more time when fetching the blame? If not, is there any
> reason not to do it always?

Ah, you mean you get two revision columns even if the merge info wasn't
requested. That's a bug of course.
Fixed in r21320.

And yes: fetching the merge info for blaming can take a long time,
that's why it's an option and off by default.

Stefan

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

Re: Blame info unclear

Author simonlarge
Full name Simon Large
Date 2011-05-07 13:50:26 PDT
Message On 7 May 2011 06:53, Stefan Küng <tortoisesvn at gmail dot com> wrote:
> On 07.05.2011 00:51, Simon Large wrote:
>> On 6 May 2011 17:19, Stefan Küng<tortoisesvn@​gmail.com>  wrote:
>>> On 05.05.2011 10:08, Simon Large wrote:
>>>> On 30 April 2011 07:43, Simon Large<simon.torto​isesvn at gmail dot com>​    wrote:
>>>>> On 3 March 2010 17:58, Stefan Küng<tortoisesvn@​gmail.com>    wrote:
>>>>>> On 03.03.2010 00:11, Davison, Steve D wrote:
>>>>>>> I can't seem to find any explanation of what the columns of
>>>>>>> the blame output (as shown in Tortoise Merge) mean.  The
>>>>>>> number of columns shown by Of course, all except for the 2
>>>>>>> revision columns at the left are pretty obvious.
>>>>>>>
>>>>>>> So why are there 2 revision columns, and what do they mean?
>>>>>>> So far, I don't think I've ever seen the two numbers
>>>>>>> differ.  It also seems strange that when blaming
>>>>>>
>>>>>> One revision is the rev where the line was last modified. The other
>>>>>> revision shows you when the line was last modified but ignoring changes
>>>>>> due to merging.
>>>>>
>>>>> Responding to a year-old thread. I just tried this by showing the log
>>>>> for a file I know has a lot of merges. In the log dialog check the
>>>>> "include merged revisions" box so that merge sources that svn knows
>>>>> about show up in grey. Right click on a revision that has a greyed
>>>>> source below it and "Blame..." taking the text file option or "Blame
>>>>> changes". The resulting output shows the merged revision in both
>>>>> columns for lines affected by that merge.
>>>>
>>>> Bump. Any clues, anyone?
>>>
>>> Blaming the file
>>> https://tortoisesvn.​googlecode.com/svn/b​ranches/1.6.x/src/To​rtoiseShell/RemoteCa​cheLink.cpp
>>>
>>>
>>> with the latest nightly build returns one merged line:
>>>
>>> G    232  15770  15771 18.03.2009 20:42:21
>>> /trunk/src/TortoiseS​hell/RemoteCacheLink​.cpp                 tortoisesvn
>>>                                 if
>>> (CreateProcess(sCach​ePath.GetBuffer(sCac​hePath.GetLength()+1​), NULL,
>>> NULL, NULL, FALSE, 0, 0, 0,&startup,&​process)==0)
>>>
>>> And there the revs differ.
>>>
>>> The same is returned when I run
>>> svn blame -g RemoteCacheLink.cpp>  RemoteCacheLink.txt
>>>
>>>
>>> So what exactly is the problem here?
>>
>> OK, I see Blame Changes is working. Blame with the text viewer also
>> shows 2 revision columns, but there is no G and the revs don't differ.
>
> How do you start blame? The line I pasted above is from a blame with
> text viewer and it clearly shows the "G".

OK I see the confusion now. If you select the 'Include merge info'
checkbox then you get the G line. If you don't check that box then you
don't get the merge info, but you still get 2 columns which are always
identical. I guess that is just a subversion 'feature'. Does the -g
option take more time when fetching the blame? If not, is there any
reason not to do it always?

Simon

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

Re: Blame info unclear

Author steveking
Full name Stefan Küng
Date 2011-05-06 22:53:13 PDT
Message On 07.05.2011 00:51, Simon Large wrote:
> On 6 May 2011 17:19, Stefan Küng<tortoisesvn@​gmail.com> wrote:
>> On 05.05.2011 10:08, Simon Large wrote:
>>> On 30 April 2011 07:43, Simon Large<simon.torto​isesvn at gmail dot com>​ wrote:
>>>> On 3 March 2010 17:58, Stefan Küng<tortoisesvn@​gmail.com> wrote:
>>>>> On 03.03.2010 00:11, Davison, Steve D wrote:
>>>>>> I can't seem to find any explanation of what the columns of
>>>>>> the blame output (as shown in Tortoise Merge) mean. The
>>>>>> number of columns shown by Of course, all except for the 2
>>>>>> revision columns at the left are pretty obvious.
>>>>>>
>>>>>> So why are there 2 revision columns, and what do they mean?
>>>>>> So far, I don't think I've ever seen the two numbers
>>>>>> differ. It also seems strange that when blaming
>>>>>
>>>>> One revision is the rev where the line was last modified. The other
>>>>> revision shows you when the line was last modified but ignoring changes
>>>>> due to merging.
>>>>
>>>> Responding to a year-old thread. I just tried this by showing the log
>>>> for a file I know has a lot of merges. In the log dialog check the
>>>> "include merged revisions" box so that merge sources that svn knows
>>>> about show up in grey. Right click on a revision that has a greyed
>>>> source below it and "Blame..." taking the text file option or "Blame
>>>> changes". The resulting output shows the merged revision in both
>>>> columns for lines affected by that merge.
>>>
>>> Bump. Any clues, anyone?
>>
>> Blaming the file
>> https://tortoisesvn.​googlecode.com/svn/b​ranches/1.6.x/src/To​rtoiseShell/RemoteCa​cheLink.cpp
>>
>>
>> with the latest nightly build returns one merged line:
>>
>> G 232 15770 15771 18.03.2009 20:42:21
>> /trunk/src/TortoiseS​hell/RemoteCacheLink​.cpp tortoisesvn
>> if
>> (CreateProcess(sCach​ePath.GetBuffer(sCac​hePath.GetLength()+1​), NULL,
>> NULL, NULL, FALSE, 0, 0, 0,&startup,&​process)==0)
>>
>> And there the revs differ.
>>
>> The same is returned when I run
>> svn blame -g RemoteCacheLink.cpp> RemoteCacheLink.txt
>>
>>
>> So what exactly is the problem here?
>
> OK, I see Blame Changes is working. Blame with the text viewer also
> shows 2 revision columns, but there is no G and the revs don't differ.

How do you start blame? The line I pasted above is from a blame with
text viewer and it clearly shows the "G".

Stefan


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

Re: Blame info unclear

Author simonlarge
Full name Simon Large
Date 2011-05-06 15:51:52 PDT
Message On 6 May 2011 17:19, Stefan Küng <tortoisesvn at gmail dot com> wrote:
> On 05.05.2011 10:08, Simon Large wrote:
>> On 30 April 2011 07:43, Simon Large<simon.torto​isesvn at gmail dot com>​  wrote:
>>> On 3 March 2010 17:58, Stefan Küng<tortoisesvn@​gmail.com>  wrote:
>>>> On 03.03.2010 00:11, Davison, Steve D wrote:
>>>>> I can't seem to find any explanation of what the columns of
>>>>> the blame output (as shown in Tortoise Merge) mean.  The
>>>>> number of columns shown by Of course, all except for the 2
>>>>> revision columns at the left are pretty obvious.
>>>>>
>>>>> So why are there 2 revision columns, and what do they mean?
>>>>> So far, I don't think I've ever seen the two numbers
>>>>> differ.  It also seems strange that when blaming
>>>>
>>>> One revision is the rev where the line was last modified. The other
>>>> revision shows you when the line was last modified but ignoring changes
>>>> due to merging.
>>>
>>> Responding to a year-old thread. I just tried this by showing the log
>>> for a file I know has a lot of merges. In the log dialog check the
>>> "include merged revisions" box so that merge sources that svn knows
>>> about show up in grey. Right click on a revision that has a greyed
>>> source below it and "Blame..." taking the text file option or "Blame
>>> changes". The resulting output shows the merged revision in both
>>> columns for lines affected by that merge.
>>
>> Bump. Any clues, anyone?
>
> Blaming the file
> https://tortoisesvn.​googlecode.com/svn/b​ranches/1.6.x/src/To​rtoiseShell/RemoteCa​cheLink.cpp
>
>
> with the latest nightly build returns one merged line:
>
> G    232  15770  15771 18.03.2009 20:42:21
> /trunk/src/TortoiseS​hell/RemoteCacheLink​.cpp                 tortoisesvn
>                                if
> (CreateProcess(sCach​ePath.GetBuffer(sCac​hePath.GetLength()+1​), NULL,
> NULL, NULL, FALSE, 0, 0, 0, &startup, &process)==0)
>
> And there the revs differ.
>
> The same is returned when I run
> svn blame -g RemoteCacheLink.cpp > RemoteCacheLink.txt
>
>
> So what exactly is the problem here?

OK, I see Blame Changes is working. Blame with the text viewer also
shows 2 revision columns, but there is no G and the revs don't differ.

Simon

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

Re: Blame info unclear

Author steveking
Full name Stefan Küng
Date 2011-05-06 09:19:12 PDT
Message On 05.05.2011 10:08, Simon Large wrote:
> On 30 April 2011 07:43, Simon Large<simon.torto​isesvn at gmail dot com>​ wrote:
>> On 3 March 2010 17:58, Stefan Küng<tortoisesvn@​gmail.com> wrote:
>>> On 03.03.2010 00:11, Davison, Steve D wrote:
>>>> I can't seem to find any explanation of what the columns of
>>>> the blame output (as shown in Tortoise Merge) mean. The
>>>> number of columns shown by Of course, all except for the 2
>>>> revision columns at the left are pretty obvious.
>>>>
>>>> So why are there 2 revision columns, and what do they mean?
>>>> So far, I don't think I've ever seen the two numbers
>>>> differ. It also seems strange that when blaming
>>>
>>> One revision is the rev where the line was last modified. The other
>>> revision shows you when the line was last modified but ignoring changes
>>> due to merging.
>>
>> Responding to a year-old thread. I just tried this by showing the log
>> for a file I know has a lot of merges. In the log dialog check the
>> "include merged revisions" box so that merge sources that svn knows
>> about show up in grey. Right click on a revision that has a greyed
>> source below it and "Blame..." taking the text file option or "Blame
>> changes". The resulting output shows the merged revision in both
>> columns for lines affected by that merge.
>
> Bump. Any clues, anyone?

Blaming the file
https://tortoisesvn.​googlecode.com/svn/b​ranches/1.6.x/src/To​rtoiseShell/RemoteCa​cheLink.cpp


with the latest nightly build returns one merged line:

G 232 15770 15771 18.03.2009 20:42:21
/trunk/src/TortoiseS​hell/RemoteCacheLink​.cpp tortoisesvn
                            if
(CreateProcess(sCach​ePath.GetBuffer(sCac​hePath.GetLength()+1​), NULL,
NULL, NULL, FALSE, 0, 0, 0, &startup, &process)==0)

And there the revs differ.

The same is returned when I run
svn blame -g RemoteCacheLink.cpp > RemoteCacheLink.txt


So what exactly is the problem here?

Stefan

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

Re: Blame info unclear

Author simonlarge
Full name Simon Large
Date 2011-05-05 01:08:10 PDT
Message On 30 April 2011 07:43, Simon Large <simon.tortoisesv​n@gmail.com> wrote:
> On 3 March 2010 17:58, Stefan Küng <tortoisesvn at gmail dot com> wrote:
>> On 03.03.2010 00:11, Davison, Steve D wrote:
>>> I can't seem to find any explanation of what the columns of
>>> the blame output (as shown in Tortoise Merge) mean.  The
>>> number of columns shown by Of course, all except for the 2
>>> revision columns at the left are pretty obvious.
>>>
>>> So why are there 2 revision columns, and what do they mean?
>>> So far, I don't think I've ever seen the two numbers
>>> differ.  It also seems strange that when blaming
>>
>> One revision is the rev where the line was last modified. The other
>> revision shows you when the line was last modified but ignoring changes
>> due to merging.
>
> Responding to a year-old thread. I just tried this by showing the log
> for a file I know has a lot of merges. In the log dialog check the
> "include merged revisions" box so that merge sources that svn knows
> about show up in grey. Right click on a revision that has a greyed
> source below it and "Blame..." taking the text file option or "Blame
> changes". The resulting output shows the merged revision in both
> columns for lines affected by that merge.

Bump. Any clues, anyone?

Simon

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

Re: Blame info unclear

Author simonlarge
Full name Simon Large
Date 2011-04-29 23:43:40 PDT
Message On 3 March 2010 17:58, Stefan Küng <tortoisesvn at gmail dot com> wrote:
> On 03.03.2010 00:11, Davison, Steve D wrote:
>> I can't seem to find any explanation of what the columns of
>> the blame output (as shown in Tortoise Merge) mean.  The
>> number of columns shown by Of course, all except for the 2
>> revision columns at the left are pretty obvious.
>>
>> So why are there 2 revision columns, and what do they mean?
>> So far, I don't think I've ever seen the two numbers
>> differ.  It also seems strange that when blaming
>
> One revision is the rev where the line was last modified. The other
> revision shows you when the line was last modified but ignoring changes
> due to merging.

Responding to a year-old thread. I just tried this by showing the log
for a file I know has a lot of merges. In the log dialog check the
"include merged revisions" box so that merge sources that svn knows
about show up in grey. Right click on a revision that has a greyed
source below it and "Blame..." taking the text file option or "Blame
changes". The resulting output shows the merged revision in both
columns for lines affected by that merge.

Simon

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

Re: Branch and Merge problem?

Author Edwin <edwintai at gmail dot com>
Full name Edwin <edwintai at gmail dot com>
Date 2010-03-07 18:37:22 PST
Message sorry for my English...in fact I just want to make sure which branch
method is best for our developers.
all the documents or article always point out one situation for branch
example.
I want to figure out how to branches when we are in development and
maintain phase.
developersafraid of branch merge effort after branch.they can use svn
log to record which revision is ready to production.
and export that revision.If we can use svn log to record revison,shoud
we need to branch?

On 3月4日, 下午7時56分, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> On Wednesday 03 March 2010, Edwin wrote:
>
> > refer to
> >http://weblogs.asp.n​et/bsimser/archive/2​008/05/06/day-to-day​-with-subv
> > ersion.aspx this is most like our case, but still have problems about real
> > operation.
> > when we branch and add new feature v1.1 in branch,other functions like
> > progress to next feature.
>
> Edwin, I'm afraid I can't help you. I simply don't understand you and I'm
> afraid you don't understand me either, both on a purely linguistic base.
> There is too many of your sentences where I can only guess what you are
> trying to say. Guessing is bad, it always allows being wrong.
>
> Sorry.
>
> Uli
>
> --
> ML:http://tortoisesvn.t​igris.org/list_etiqu​ette.html
> FAQ:http://tortoisesvn.net/faq
>
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
> ********************​********************​********************​***************­****​*******
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> ********************​********************​********************​***************­****​*******
>            Visit our website at <http://www.satorlaser.de/>
> ********************​********************​********************​***************­****​*******
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
> ********************​********************​********************​***************­****​*******
>
> --------------------​--------------------​--------------http://tortoisesvn.t​igris.org/ds/viewMes​sage.do?dsForumId=40​61&dsMess...
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr...@t​ortoisesvn.tigris.or​g].

Re: Branch and Merge problem?

Author doomster
Full name Ulrich Eckhardt
Date 2010-03-04 03:56:45 PST
Message On Wednesday 03 March 2010, Edwin wrote:
> refer to
> http://weblogs.asp.n​et/bsimser/archive/2​008/05/06/day-to-day​-with-subv
> ersion.aspx this is most like our case, but still have problems about real
> operation.
> when we branch and add new feature v1.1 in branch,other functions like
> progress to next feature.

Edwin, I'm afraid I can't help you. I simply don't understand you and I'm
afraid you don't understand me either, both on a purely linguistic base.
There is too many of your sentences where I can only guess what you are
trying to say. Guessing is bad, it always allows being wrong.

Sorry.

Uli

--
ML: http://tortoisesvn.t​igris.org/list_etiqu​ette.html
FAQ: http://tortoisesvn.net/faq

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

********************​********************​********************​********************​******
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
********************​********************​********************​********************​******
           Visit our website at <http://www.satorlaser.de/>
********************​********************​********************​********************​******
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
********************​********************​********************​********************​******

Re: Blame info unclear

Author steveking
Full name Stefan Küng
Date 2010-03-03 09:59:01 PST
Message On 03.03.2010 00:11, Davison, Steve D wrote:
> I can't seem to find any explanation of what the columns of
> the blame output (as shown in Tortoise Merge) mean. The
> number of columns shown by Of course, all except for the 2
> revision columns at the left are pretty obvious.
>
> So why are there 2 revision columns, and what do they mean?
> So far, I don't think I've ever seen the two numbers
> differ. It also seems strange that when blaming

One revision is the rev where the line was last modified. The other
revision shows you when the line was last modified but ignoring changes
due to merging.

> differences, deleted lines show rev date they were last
> modified or added, rather than the rev when it was deleted.
> That has got to be a bug.

Not really, if you check the blame in TMerge then two blames are diffed.
One blame for the revision before the deletion, and one for after.

Stefan

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

Re: Branch and Merge problem?

Author Edwin <edwintai at gmail dot com>
Full name Edwin <edwintai at gmail dot com>
Date 2010-03-03 08:55:10 PST
Message refer to http://weblogs.asp.n​et/bsimser/archive/2​008/05/06/day-to-day​-with-subversion.asp​x
this is most like our case, but still have problems about real
operation.
when we branch and add new feature v1.1 in branch,other functions like
progress to next feature.
in our case we has three team to develop project

designer (D),artist(A),programmer(P)
D response produce function spec documens first
A draw pics use D spec
P coding use D spec

so milestone v1.1 sequence would be
D first finish their job v1.1 ,then to v1.2
A second finish their job v1.1 then to v.1.2
P final finish their job v1.1 then to v1.2
if we branch v1.2 to add new feature,the code will still v1.0 status
that would be large code to merge back to trunk and v1.2 isn't it?
and if D works fast they could progress to v1.3 and P still in v1.1
coding

Re: Branch and Merge problem?

Author doomster
Full name Ulrich Eckhardt
Date 2010-03-03 04:14:32 PST
Message On Wednesday 03 March 2010, Edwin wrote:
> In my operation case, all of our production go publish need to pass QA
> testing and then on board.
> if there are bugs in earlier version which is production already,we
> have to fix in few hours.
> if the bugs are already fixed in QA ex.v1.1.0 is production v1.1.1
> testing not finish
> we need to fix v1.1.0 first before v1.1.1 testing finish because it's
> real emergency.
> if we fix and wait until v1.1.1 testing finish go production,
> that would not on time and may include other bugs in v1.1.1 ,every
> changes may casue other problems should consider.

Okay. If I understand correctly (which I'm not sure, it is hard to follow your
intentions here), then your understanding of branches and tags is different
from the one suggested by Subversion.

> branch merge conflicts I think we could resovle it by hands,
> I only worry about if we don't branch when we fix bugs in new branch.
> ex.
> 1.we fix bugs in branch v1.1.0 then tags v1.1.1
> 2.QA report bugs we fix bugs v1.1.0 too and tags v1.1.2
> 3.when we need to fix v1.1.1 is there have good way to use
> In my opinion,we can use branch v1.1.1 fix it and merge to v1.1.2
> but there is a company policy,we can't fix in tags and we can't branch
> other 1.1 version in branches

If you suddenly start changing 1.1.1 from being a tag (which is a symbolic
name for exactly one state) to being a branch (which is an independent stream
of development), then Subversion terminology does not apply. Then you are
using your own definition of what branches and tags are, and the whole
discussion that implies the terminology suggested by Subversion is moot.

You can do that, but don't ask me how braching and tagging should behave when
you yourself are making the rules. I can then only help you with the use of
Subversion, i.e. the technical part.

Uli

--
ML: http://tortoisesvn.t​igris.org/list_etiqu​ette.html
FAQ: http://tortoisesvn.net/faq

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

********************​********************​********************​********************​******
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
********************​********************​********************​********************​******
           Visit our website at <http://www.satorlaser.de/>
********************​********************​********************​********************​******
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
********************​********************​********************​********************​******

Re: Branch and Merge problem?

Author Edwin <edwintai at gmail dot com>
Full name Edwin <edwintai at gmail dot com>
Date 2010-03-02 19:51:29 PST
Message In my operation case, all of our production go publish need to pass QA
testing and then on board.
if there are bugs in earlier version which is production already,we
have to fix in few hours.
if the bugs are already fixed in QA ex.v1.1.0 is production v1.1.1
testing not finish
we need to fix v1.1.0 first before v1.1.1 testing finish because it's
real emergency.
if we fix and wait until v1.1.1 testing finish go production,
that would not on time and may include other bugs in v1.1.1 ,every
changes may casue other problems should consider.

branch merge conflicts I think we could resovle it by hands,
I only worry about if we don't branch when we fix bugs in new branch.
ex.
1.we fix bugs in branch v1.1.0 then tags v1.1.1
2.QA report bugs we fix bugs v1.1.0 too and tags v1.1.2
3.when we need to fix v1.1.1 is there have good way to use
In my opinion,we can use branch v1.1.1 fix it and merge to v1.1.2
but there is a company policy,we can't fix in tags and we can't branch
other 1.1 version in branches

Blame info unclear

Author "Davison, Steve D" <steve dot d dot davison at intel dot com>
Full name "Davison, Steve D" <steve dot d dot davison at intel dot com>
Date 2010-03-02 15:12:19 PST
Message I can't seem to find any explanation of what the columns of
the blame output (as shown in Tortoise Merge) mean. The
number of columns shown by Of course, all except for the 2
revision columns at the left are pretty obvious.

So why are there 2 revision columns, and what do they mean?
So far, I don't think I've ever seen the two numbers
differ. It also seems strange that when blaming
differences, deleted lines show rev date they were last
modified or added, rather than the rev when it was deleted.
That has got to be a bug.

my version is 1.6.7, r18415 32-bit

Re: Branch and Merge problem?

Author doomster
Full name Ulrich Eckhardt
Date 2010-03-02 00:56:17 PST
Message On Tuesday 02 March 2010, Edwin wrote:
> > I don't see why you need to base your new bugfix release on exactly
> > 1.1.1. I would expect that only real bugfixes and not new features enter
> > the 1.1.x branch, i.e. that it remains relatively stable otherwise. So,
> > if a user reports an error in 1.1.1, the first thing I would do is to
> > check if 1.1.2 doesn't already include a fix for it. Otherwise, just grab
> > the 1.1.x branch, apply a bugfix and afterwards tag version 1.1.3 which
> > you then give to the user.
>
> in our real operation environment,1.1.1 is production version,1.1.2 is
> QA/QT version.
> when 1.1.1 has bugs in production,we should fixed it first before
> 1.1.2.
> 1.1.2 may include 1.1.1 bugs but we should fix 1.1.1 first and quickly
> test to production again.

I don't understand why you make that distinction. When I'm confident (all unit
tests pass) with a version, I just release it as 1.1.0. This version will
then be used as base for integration testing. If problems come up there, I
will adjust the 1.1 branch accordingly and then release 1.1.1 as a bugfix
release to 1.1.0. This can repeat several times before e.g. 1.1.8 is shipped
to customers.

Note that other projects provide "release candidates", which is a different
way of saying the same thing. There, before actually releasing 1.1.0, they
tag a version 1.1.0-rc1. Further bugfixes then lead to 1.1.0-rc2 etc until
they eventually release the full 1.1.0 which is the same as the last -rc
version.

> could we use tag to debug? if not,which version should we use to fixed
> and commit?

Tags, by convention, are immutable. Of course you are free to ignore that
convention and modify tags, Subversion doesn't attach any particular meaning
to them, but that would render any discussion useless that assumes
their "normal" meaning.

> in branch folder we only have 1.1.x and latest version may already
> 1.1.3.
> so I think if we don't use branch folder,we should use revert to
> revision

Why not base your new version on 1.1.3 then? If the changes between 1.1.1 and
1.1.3 are too great (changed APIs, added features etc) why not name this
thing 1.2.0 instead[1]? If the changes are just small bugfixes, then
replacing a 1.1.1 with that version shouldn't matter, it just contains
additional bugfixes.

Anyway, what _you_ want, and how _you_ want to name it is all up to _you_ to
decide. I can make suggestions, but I don't know your workflow well enough to
make a well-informed decision.


All that said, you mentioned tree conflicts and missing MD5 checksums. Those
indeed are technical issues that are governed by Subversion, but for those
you haven't supplied enough info yet to tell you what went wrong and how to
fix it.

Uli

[1] An often-used convention is that with x.y.z, z changes mean 100%
compatible bugfixes, y changes mean added features with backward
compatibility and x changes mean incompatible changes.

--
ML: http://tortoisesvn.t​igris.org/list_etiqu​ette.html
FAQ: http://tortoisesvn.net/faq

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

********************​********************​********************​********************​******
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
********************​********************​********************​********************​******
           Visit our website at <http://www.satorlaser.de/>
********************​********************​********************​********************​******
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
********************​********************​********************​********************​******

Re: Branch and Merge problem?

Author Edwin <edwintai at gmail dot com>
Full name Edwin <edwintai at gmail dot com>
Date 2010-03-01 18:14:10 PST
Message > I don't see why you need to base your new bugfix release on exactly 1.1.1. I
> would expect that only real bugfixes and not new features enter the 1.1.x
> branch, i.e. that it remains relatively stable otherwise. So, if a user
> reports an error in 1.1.1, the first thing I would do is to check if 1.1.2
> doesn't already include a fix for it. Otherwise, just grab the 1.1.x branch,
> apply a bugfix and afterwards tag version 1.1.3 which you then give to the
> user.
in our real operation environment,1.1.1 is production version,1.1.2 is
QA/QT version.
when 1.1.1 has bugs in production,we should fixed it first before
1.1.2.
1.1.2 may include 1.1.1 bugs but we should fix 1.1.1 first and quickly
test to production again.

> > But I can’t merge successful now. It always report error tree conflict
> > or md5-checksum not present error message. Am I wrong?
>
> Actually, I just hope that I understood what you were doing. Your description
> is a bit vague. In any case, I guess the problem is that you want to "revert
> to 1.1.x revision 100", which I believe is simply wrong and/or unnecessary,
> but maybe I just don't understand what it is you're trying to do.
could we use tag to debug? if not,which version should we use to fixed
and commit?

in branch folder we only have 1.1.x and latest version may already
1.1.3.
so I think if we don't use branch folder,we should use revert to
revision

best regards :)

Re: Branch and Merge problem?

Author doomster
Full name Ulrich Eckhardt
Date 2010-03-01 04:27:52 PST
Message On Monday 01 March 2010, Edwin wrote:
> In the past time, I branch from trunk when I achieve milestone.
> Root /trunk
> /branch/1.1.1
> If it has bugs need to fix,I branch from 1.1.1 become
> Root /trunk
> /branch/1.1.1
> /branch/1.1.2
> If it has bugs need to fix,I branch from 1.1.2 become
> Root /trunk
> /branch/1.1.1
> /branch/1.1.2
> /branch/1.1.3
> When 1.1.3 fixing,1.1.1 has bugs to fixed, I need to fix 1.1.1 branch
> and merge 1.1.1 to 1.1.2 to 1.1.3 and finally merge back to trunk

This is rather unusual. Typically, a version triplet like 1.1.2 is the name of
a tag. It would be the third tag (0, 1, 2) which was created from the 1.1
branch.
Further, it looks like you have the branch folder underneath the trunk folder,
which is also unusual. The typical setup would have those at the same level.

> It spends much time to checkout each version, so now we change to
> another branch method. We use 1.1.X to replace 1.1.1 now become
>
> Root /trunk
> /branch/1.1.x revision 100
> If there is no bugs to fix, We tag 1.1.1 from 1.1.x
> Root /trunk
> /branch/1.1.x
> /tag/1.1.1 revision 101
> If it has bugs to fix, we fix on 1.1.x and then tag to 1.1.2 become
> Root /trunk
> /branch/1.1.x revision 120
> /tag/1.1.1
> /tag/1.1.2 revision 121
> So 1.1.x has latest fix in branch, we only need to merger 1.1.x and
> trunk

Yes, this more closely resembles the typical behaviour.

> But here comes a problem if 1.1.1 report bugs, we need to revert to
> 1.1.x revision 100 and commit become revision 122 to fix bugs may
> become revision 130. After revert we lost 1.1.2 revision 120’s fixed.
> We need to merge 120 and 130.

I don't see why you need to base your new bugfix release on exactly 1.1.1. I
would expect that only real bugfixes and not new features enter the 1.1.x
branch, i.e. that it remains relatively stable otherwise. So, if a user
reports an error in 1.1.1, the first thing I would do is to check if 1.1.2
doesn't already include a fix for it. Otherwise, just grab the 1.1.x branch,
apply a bugfix and afterwards tag version 1.1.3 which you then give to the
user.

> But I can’t merge successful now. It always report error tree conflict
> or md5-checksum not present error message. Am I wrong?

Actually, I just hope that I understood what you were doing. Your description
is a bit vague. In any case, I guess the problem is that you want to "revert
to 1.1.x revision 100", which I believe is simply wrong and/or unnecessary,
but maybe I just don't understand what it is you're trying to do.

Cheers!

Uli

--
ML: http://tortoisesvn.t​igris.org/list_etiqu​ette.html
FAQ: http://tortoisesvn.net/faq

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

********************​********************​********************​********************​******
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
********************​********************​********************​********************​******
           Visit our website at <http://www.satorlaser.de/>
********************​********************​********************​********************​******
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
********************​********************​********************​********************​******

Branch and Merge problem?

Author Edwin <edwintai at gmail dot com>
Full name Edwin <edwintai at gmail dot com>
Date 2010-03-01 00:37:24 PST
Message In the past time, I branch from trunk when I achieve milestone.
Root /trunk
        /branch/1.1.1
If it has bugs need to fix,I branch from 1.1.1 become
Root /trunk
        /branch/1.1.1
        /branch/1.1.2
If it has bugs need to fix,I branch from 1.1.2 become
Root /trunk
        /branch/1.1.1
        /branch/1.1.2
        /branch/1.1.3
When 1.1.3 fixing,1.1.1 has bugs to fixed, I need to fix 1.1.1 branch
and merge 1.1.1 to 1.1.2 to 1.1.3 and finally merge back to trunk

It spends much time to checkout each version, so now we change to
another branch method. We use 1.1.X to replace 1.1.1 now become

Root /trunk
       /branch/1.1.x revision 100
If there is no bugs to fix, We tag 1.1.1 from 1.1.x
Root /trunk
        /branch/1.1.x
        /tag/1.1.1 revision 101
If it has bugs to fix, we fix on 1.1.x and then tag to 1.1.2 become
Root /trunk
        /branch/1.1.x revision 120
        /tag/1.1.1
        /tag/1.1.2 revision 121
So 1.1.x has latest fix in branch, we only need to merger 1.1.x and
trunk
But here comes a problem if 1.1.1 report bugs, we need to revert to
1.1.x revision 100 and commit become revision 122 to fix bugs may
become revision 130. After revert we lost 1.1.2 revision 120’s fixed.
We need to merge 120 and 130.
But I can’t merge successful now. It always report error tree conflict
or md5-checksum not present error message. Am I wrong?
Messages per page: