Login | Register
My pages Projects Community openCollabNet

Discussions > users > Re: Branch and Merge problem?

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

tortoisesvn
Discussion topic

Back to topic list

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.
********************​********************​********************​********************​******

« Previous message in topic | 4 of 19 | Next message in topic »

Messages

Show all messages in topic

Branch and Merge problem? Edwin <edwintai at gmail dot com> Edwin <edwintai at gmail dot com> 2010-03-01 00:37:24 PST
     Re: Branch and Merge problem? doomster Ulrich Eckhardt 2010-03-01 04:27:52 PST
         Re: Branch and Merge problem? Edwin <edwintai at gmail dot com> Edwin <edwintai at gmail dot com> 2010-03-01 18:14:10 PST
             Re: Branch and Merge problem? doomster Ulrich Eckhardt 2010-03-02 00:56:17 PST
                 Blame info unclear "Davison, Steve D" <steve dot d dot davison at intel dot com> "Davison, Steve D" <steve dot d dot davison at intel dot com> 2010-03-02 15:12:19 PST
                     Re: Blame info unclear steveking Stefan Küng 2010-03-03 09:59:01 PST
                         Re: Blame info unclear simonlarge Simon Large 2011-04-29 23:43:40 PDT
                             Re: Blame info unclear simonlarge Simon Large 2011-05-05 01:08:10 PDT
                                 Re: Blame info unclear steveking Stefan Küng 2011-05-06 09:19:12 PDT
                                     Re: Blame info unclear simonlarge Simon Large 2011-05-06 15:51:52 PDT
                                         Re: Blame info unclear steveking Stefan Küng 2011-05-06 22:53:13 PDT
                                             Re: Blame info unclear simonlarge Simon Large 2011-05-07 13:50:26 PDT
                                                 Re: Blame info unclear steveking Stefan Küng 2011-05-07 23:18:02 PDT
                                                     Re: Blame info unclear simonlarge Simon Large 2011-05-10 13:27:11 PDT
                 Re: Branch and Merge problem? Edwin <edwintai at gmail dot com> Edwin <edwintai at gmail dot com> 2010-03-02 19:51:29 PST
                     Re: Branch and Merge problem? doomster Ulrich Eckhardt 2010-03-03 04:14:32 PST
                         Re: Branch and Merge problem? Edwin <edwintai at gmail dot com> Edwin <edwintai at gmail dot com> 2010-03-03 08:55:10 PST
                             Re: Branch and Merge problem? doomster Ulrich Eckhardt 2010-03-04 03:56:45 PST
                                 Re: Branch and Merge problem? Edwin <edwintai at gmail dot com> Edwin <edwintai at gmail dot com> 2010-03-07 18:37:22 PST
Messages per page: