2008/12/21 Guilherme Polo <[email protected]>: > 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.
Not necessary. My branch is a little outdated and after the merge into trunk I've preferred to work directly on trunk because svn is lesser usable than git if you have multiple branches. It was only a choice to improve simplicity of operations. > 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. The change in this case was minimum so no worry about testing, it was only a stupid fix. And, yes, for me it's better to delete the merged branches. > 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, > I prefer to use svn merge command without blocking anything and not dirty repo logs. Btw everyone is free to choose. +1 for the defining rules necessary to avoid these problems and sorry for the mistake but I don't have a protocol to follow so I did my best -- Best regards, Francesco Piccinno ------------------------------------------------------------------------------ _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
