On Sun, Dec 21, 2008 at 12:48 PM, Francesco Piccinno <[email protected]> wrote: > 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.
Huh ? That is not the problem it creates, and I also said "... manage the trunk", not my branch. The problem it creates is when it starts breaking the trunk, given that we have no tests at all that is easy to go unnoticed. There was also no reason to commit that directly into trunk, as noted before. It also confuses anyone that checkouts your branch, since the trunk is more up-to-date than it. Of course this all is not a problem for /you/, because it is you who did the commit, and you know your branch is like that, but everyone else don't have to know that. If I saw that the log message mentioning the changes were merged from your branch I could opt to block it or merge it on my own branch, and again, svnmerge makes it easy to undo merges in case things go wrong. >> >>> >>>> 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 > -- -- Guilherme H. Polo Goncalves ------------------------------------------------------------------------------ _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
