Hi, On Sun, Dec 21, 2008 at 1:50 PM, Guilherme Polo <[email protected]> wrote:
> 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. Yeah, we need define rules for commiting. Once it defined we have a workflow. What we did in the past, wrong or not it's already done. So may be we can run to fix it. > > 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; Well, If we already integrate a branch, is it make sense? How effort we will put on that? I confess that I'm never use svnmerge before. But I'm trying to merge my branch with it. If it can bring some kind of benefits I'll do the same with RadialNet too. > 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 Basically did you block manually merge that you did using svn merge? > > (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, Of course. I would like to test it first. After that I will give my opinion. > > > > Regards, > > -- > -- Guilherme H. Polo Goncalves > > > ------------------------------------------------------------------------------ > _______________________________________________ > Umit-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/umit-devel > Regards, -- Luis A. Bastiao Silva
------------------------------------------------------------------------------
_______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
