Re: Branch and Merge problem?

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.tigris.org/list_etiquette.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.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2453877
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].