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 ------------------------------------------------------------------------------ _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
