2008/12/21 Guilherme Polo <[email protected]>: > On Sun, Dec 21, 2008 at 12:15 PM, Francesco Piccinno > <[email protected]> wrote: >> 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. > > That is the reason of my proposal to use svnmerge, since it solves two > of the three advantages git branches has over svn branches. It tracks > the merges you do. > >> It was only a choice to >> improve simplicity of operations. > > For yourself, not for anyone else in the project that attempts to > manage the trunk.
What problems I've created? I don't think your branch use Tree.py of UmitPlugin. > >> >>> 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. > > Doesn't matter, really. > >> And, yes, for me it's better to delete the merged >> branches. > > Your branch is not one that applies to "delete the branch" part of my > phrase. It uses umitCore and umitGUI files and it is inevitable that > sometime you will be touching these files, and your own umitPlugin > depends on it so it is all a reason to keep the branch around. > >> >>> 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. > > You have never used svnmerge, have you ? Given the start of your email > where you mention git, I will take it is as "no, I haven't". It's not a question of what tool is better. The question is that we don't have rules to follow. > For the "dirty repo logs" part, well, it is clearly not dirty but you > could check some of your own commit messages to check what dirty repo > logs means. We don't have neither a commit log rules so why don't you define one for us? > >> 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 >> > > > -- > -- Guilherme H. Polo Goncalves > -- Best regards, Francesco Piccinno ------------------------------------------------------------------------------ _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
