Hi there,
I wouldn't be posting there had I not seen nopper's last commit on
trunk, but it should serve for everyone else too.
Let me talk more about the specific commit that made me write this,
the affected files are trunk/umit and trunk/umitPlugins/Tree.py. I'm
fine with the former, it is a nice one, the later is probably also
fine but notice it is changing a file inside umitPlugins which lives
in the branch UmitPlugins.
One would naturally think that a branch would contain the most updated
files related to the branch (like umitPlugins/Tree.py here), but there
is something very wrong going on here, for some reason the branch
UmitPlugins (and maybe others, but I didn't check) have specific files
in the branch that are outdated when compared to the ones merged into
trunk. That just can't be right.
Any file being changed that has its own branch should first be changed
in the branch, tested if the change is substantial, and only then
merged into trunk. If this is not going to happen, just delete the
branch and let the trunk be a mess.
I'm almost forgetting about email's title: "Defining rules for comitting"
We should set some rules for using umit's repository now that there a
couple of branches, some of them merged into trunk. I will not be
trying to make your life harder, on the contrary.
These are the rules that come to my mind right now:
1. Initialize svnmerge on your branch;
2. Initialize svnmerge from the trunk to your branch if you are
planning to merge your branch into trunk, or if the branch has already
been merged;
3. If you are planning to change something:
i) If the thing has a branch for it, change the thing that lives
in the branch
ii) If the thing is trunk-specific, then just change it
4. If you are planning to commit something:
i) if the thing has a branch for it, the commit should be done in
the branch
ii) if the thing is trunk-specific, then there should be a ticket
in the trac *
iii) if you are merging something into trunk, use svnmerge and then
use the generated commit msg file to commit
* There could be exceptions on this.
Initially it will be a pain to use svnmerge, at least it was in my
branch, because it will mark up to the last trunk commit as already
integrated in your branch (or from the trunk to your branch). When
creating new branches we should enforce these rules if the branch has
any interest in being merged into the trunk, and everything will be
easier.
So in the case of my branch, it has been around 1 year since I did
something on it, and about 10 months since I (manually) merged changes
from the trunk to it, so there were a lot of new changes to be merged.
What I did was block (using svnmerge) the revisions I didn't want
based on: branch creation and merges that were already manually merged
(this one was what caused some trouble), the rest of the changes were
merged and solved conflicts manually where necessary. Now that it has
svnmerge with proper revisions merged and blocked, it gets much easier
to manage changes from the trunk, and after I merge it into trunk it
will also get very easy to sync changes from my branch to the trunk.
I hope you consider using something as noted,
Regards,
--
-- Guilherme H. Polo Goncalves
------------------------------------------------------------------------------
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
