Done 2008/12/21 Francesco Piccinno <[email protected]>: > I'll update my branch ASAP. > > 2008/12/21 Guilherme Polo <[email protected]>: >> 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 >> > > > > -- > Best regards, > Francesco Piccinno >
-- Best regards, Francesco Piccinno ------------------------------------------------------------------------------ _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
