Yes Jervis, these are good points - and given your experience with releasing drools (compared to me!) I cannot question them.

However I still wonder whether the branches *you* need for *your* work should be maintained in *your* local repo? Somebody else might prefer to solve issues another way. I don't think anybody would ever want to impose process or restrictions on the way we work as individuals - I am thinking about the "public\community" view of what is in our "public\reference" repo.

Ge0ffrey,

So a "tree revision" is like a system assigned label\tag across the entire repo at the point in time of a push and a commit is (obviously) just a set of files that changed in a particular commit?

Cheers,

Mike

On 23 December 2010 12:04, Geoffrey De Smet <ge0ffrey.spam@gmail.com> wrote:
Jervis, those are all good points,
but I agree with Michael, it should be clear what the real M1 branch is on the reference repository,
(so the real one should be named 5.1.0.M1.x and there mustn't be another one with a similar name causing confusion).

There's nothing stopping you from making local branches, or tagging the old end result (or just remember the tree revision).
Note the difference in Git between:
Compare the 2 URL's.
Each commit revision has a parent commit revision. Each tree revision has a parent tree revision.

Op 23-12-10 12:09, Jervis Liu schreef: 
Michael Anstis wrote:

I don't understand why we'd have multiple branches for a single release.

Surely any fixes needed for the release would be made in the single 
branch?

If we need to make another branch for a single release it suggests 
something fundamentally wrong with the original branch, so why not 
delete and re-create, leaving a single "5.2.0-M2.x" branch?


Ok, one use case is that there is sth wrong with the old branch, so we 
have to create a new. This is exactly what happened right now. Toni 
created one last Friday, then we decided we need a new branch as we need 
some changes committed this Monday. So we create a new one. But for the 
purpose of testing, I will still need the old branch keep alive for a 
while, as some tests failed on the new branch while everything passed on 
the old branch. I need to run tests both on the old branch as well as 
the new branch to figure out whats going wrong.

In this case, we have two choices. One is just creating a new branch, we 
may give it a more sensible name such as 5.2.0-M1.attempt2 (or whatever 
makes more sense). Another is as Geoffrey suggested, we merge:

"git checkout 901ad86c8fad67051646738e84d3974420b9e58a; git checkout -b 
myNewBranchProposal; do changes; git commit -m ""; ok the new branch is 
better; git checkout 5.1.0.M1.x; git merge myNewBranchProposal; ok looks 
fine here; git branch -d myNewBranchProposal; git push"

Personally I would prefer option one as I want to have a very clean and 
trackable history on the branch I am using for release. and I want to 
avoid using merge as much as possible, at least this is the experience 
with svn. You never know, you may end up using hours to resolve 
conflicts while you can get a clean and fresh branch in a minute by 
creating a new one.

Consider what just happened: We've done several changes on branch 
5.2.0.M1.x since it was created last Friday. Bear in mind, these changes 
are not applied to the master. One major change is the change of version 
number from 5.2.0-SNAPSHOT to 5.2.0-M1 on more than 20 places(pom file, 
doc file etc). Now we say we will take the merge approach. So we merge 
901ad86c8fad67051646738e84d3974420b9e58a (which is the version created 
this Monday) to branch 5.2.0.M1.x.  It is likely that we will have merge 
conflict with these pom files. Instead of resolving merge conflicts why 
dont I just create a branch off from 
901ad86c8fad67051646738e84d3974420b9e58a, then run update_version.xml to 
update version info for the release. It will only take me 5 minutes.

Jervis

If our "internal" team is confused what hope does our community have?

Cheers,

Mike

On 23 December 2010 09:47, Jervis Liu <jliu@redhat.com 
<mailto:jliu@redhat.com>> wrote:

    On 2010/12/23 17:27, Geoffrey De Smet wrote:
    > Not that I am mad, but yea, git knows which parent revision it
    came from
    > and even which commits were cherry picked from master etc.
    > Sticking the revision in there isn't really useful, as it's not
    really
    > the revision that is going to be released:
    > there will be bugfix commits applied and possibly even big
    merges from
    > master.
    >
    > What is bad, is the confusion this creates for anyone who isn't
    working
    > on the release.
    > What is the release branch for M1? Is it /5.2.0.M1.x/ or
    /5.2.0-M1.901ad86/?
    > /There can only be one./ And the rest of us need to be able to
    guess it.
    >
    > So follow the naming convention we discussed earlier:
    >
    >     * all release branches should end in ".x"
    >           o To avoid confusing them with release tags or topic
    branches
    >     * all release tags should be equal to the version the represent
    >           o and a tag should only be set just before it's
    uploaded to
    >             the maven repo and then NEVER changed
    >                 + Yes, with never I mean even if the release is
    broken.
    >                   Then just do a hotfix .1 (for example 5.1.1 or
    >                   5.2.0.M1.1) version
    >                       # because maven repo's are cached locally
    forever.
    >
    I do understand the idea here. Though I just thought the .x is a
    suffix
    we can use to distinguish different branches we'v created for the same
    release. For example, for this release we've already had two branches,
    the first one is 5.2.0-M1.x. To distingush the new branch from
    existing
    one, I name it as 5.2.0-M1.901ad86, which is essentially equal to
    5.2.0-M1.2.

    5.2.0-M1.2 can be interpreted as "attempt 2 for release 5.2.0-M1",
    while
    5.2.0-M1.901ad86 can be interpreted as "attempt for release 5.2.0-M1
    whose version is based on 901ad86", IMO more illustrative than ".2".

    Did I get this right or I am still missing sth?

    Thanks,
    Jervis



    > for example:
    >
    >     * release branch 5.1.x
    >           o with release tags 5.1.0.CR1, 5.1.0.FINAL, 5.1.1.FINAL
    >     * release branch 5.2.0.M1.x
    >           o with release tags 5.2.0.M1
    >     * release branch 5.2.0.M2.x
    >           o with release tags 5.2.0.M2
    >     * release branch 5.2.x
    >           o with release tags 5.2.0.CR1, 5.2.0.FINAL, 5.2.1.FINAL
    >
    > Depending on the JBoss version number conventions, the finals
    release
    > versions should end in FINAL or GA or nothing.
    > It looks like it's ".FINAL" these days, not sure.
    > WDYT?
    >
    > Op 23-12-10 09:41, Michael Anstis schreef:
    >> Ge0ffrey won't be happy ;)
    >>
    >> I'm sure he was keen to drop the revision\version number from the
    >> branch name; hence 5.2.0-M1 would probably have sufficed :)
    >>
    >> Cheers,
    >>
    >> Mike
    >>
    >> On 23 December 2010 06:22, Jervis Liu <jliu@redhat.com
    <mailto:jliu@redhat.com>
    >> <mailto:jliu@redhat.com <mailto:jliu@redhat.com>>> wrote:
    >>
    >>     Hi, I've created a new branch for Drools 5.2.0-M1 release:
    >>     5.2.0-M1.901ad86. This branch is created from version
    >>     901ad86c8fad67051646. Check
    >>    
    https://github.com/droolsjbpm/droolsjbpm/commits/master?page=1 for
    >>     version details. Please let me know if you think this branch
    >>     should not
    >>     contain a certain commit or a certain commit for 5.2.0-M1
    release is
    >>     missed on this branch.
    >>
    >>     Cheers,
    >>     Jervis
    >>     _______________________________________________
    >>     rules-dev mailing list
    >>     rules-dev@lists.jboss.org
    <mailto:rules-dev@lists.jboss.org>
    <mailto:rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>>
    >>     https://lists.jboss.org/mailman/listinfo/rules-dev
    >>
    >>
    >>
    >> _______________________________________________
    >> rules-dev mailing list
    >> rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    >> https://lists.jboss.org/mailman/listinfo/rules-dev
    >
    > --
    > With kind regards,
    > Geoffrey De Smet
    >
    >
    >
    > _______________________________________________
    > rules-dev mailing list
    > rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    > https://lists.jboss.org/mailman/listinfo/rules-dev

    _______________________________________________
    rules-dev mailing list
    rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    https://lists.jboss.org/mailman/listinfo/rules-dev


------------------------------------------------------------------------

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
  

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



-- 
With kind regards,
Geoffrey De Smet

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev