Menu
▾
▴
xmlvm-users
|
From: Arno P. <ar...@pu...> - 2011-01-10 00:04:45
|
Guys, we had some internal discussions regarding the future of XMLVM from a project management perspective. Right now there are three core team members (Sascha, Wolfgang, and myself) who are the only ones to have commit rights. Contributors have to submit their patches to an online review system where the core team members review the patch and if accepted, commit it to the Subversion repository by mentioning the name of the contributor in the commit log. We have laid out the guidelines concerning coding conventions that can be found at: http://xmlvm.org/contribute/ We believe that in order to grow as a project, we need to be more flexible with regards to this process. In the long run the current model does not scale with regards to the amount of work. We propose to introduce a new role within the XMLVM project: the role of a committer. A committer, just like the core team members, has commit rights to the Subversion repository. The core team can offer a contributor the role of committer if the contributor has proven him-/herself over a period of time to deliver high-quality patches that follow XMLVM coding conventions. A committer typically is responsible for a certain module within XMLVM. Within that module, the committer can make changes according to his or her discretion. If a change is necessary outside that module, the modification should be done by consulting the core team. As a good practice, major changes should be discussed on the mailing list anyways. If a committer repeatedly violates XMLVM coding conventions, the core team member can rescind the commit rights. We would like to put these guidelines up for discussion on the mailing list. We believe that it will help grow XMLVM as well as acknowledge and recognize significant contributions by some developers. The XMLVM Core Team |
|
From: Paul P. <bay...@gm...> - 2011-01-10 20:37:52
|
I have to admit I like you three being sorts of gatekeepers to the repository to make sure not just anything is making it in. But I also understand having only 3 people becomes more difficult as the project grows. That being said, I have a few thoughts, and they are just that, so anyone feel free to reject, improve or approve the following. I think this is a good discussion to be had. What if you begin allowing certain committers, but only you 3 have commit access to trunk. I.e. we begin using branches & tags. Exhibit #1: http://en.wikipedia.org/wiki/Apache_Subversion#Branching_and_tagging If we started today, we would immediately make tag 1.0.0 from trunk. Since most will not be committing to trunk, there's a couple of options for branches, but here's one. There is a primary development branch into which all completed work will be done. Any committer can put their work there, but should only commit finished milestones, not works in progress. More advanced developers can create a personal branch, in which works in progress may be committed. E.g. I may make "xmlvm/branches/ppoley/synchronizedSupport". When finished, they will merge their work into the development branch with a comment such as: "Support for synchronization merge -r5260:5283 http://xmlvm.svn.sourceforge.net/svnroot/xmlvm/branches/ppoley/synchronizedSupport " Any unwanted commits will be reverse merged out of the branch. Since only the 3 will have access to trunk, they will merge a set of stable changes into trunk from time to time & then immediately make a new tag to mark the milestone. This still puts somewhat of a bottle neck on the 3, but a much smaller one since this doesn't have to be done for each change. One downside is not immediately being able to immediately see original committer when looking at trunk, but if the merge into trunk is done in the same manner as above including the merge command, you can go to that branch & see who did what. In this way, the development branch does not change. If for some reason we felt the development branch had been corrupted by changes that didn't make it to trunk, we could delete the branch & recreate it from trunk at the same location. Thanks, Paul On Sun, Jan 9, 2011 at 6:03 PM, Arno Puder <ar...@pu...> wrote: > > Guys, > > we had some internal discussions regarding the future of XMLVM from a > project management perspective. Right now there are three core team > members (Sascha, Wolfgang, and myself) who are the only ones to have > commit rights. Contributors have to submit their patches to an online > review system where the core team members review the patch and if > accepted, commit it to the Subversion repository by mentioning the name > of the contributor in the commit log. We have laid out the guidelines > concerning coding conventions that can be found at: > http://xmlvm.org/contribute/ > > We believe that in order to grow as a project, we need to be more > flexible with regards to this process. In the long run the current model > does not scale with regards to the amount of work. > > We propose to introduce a new role within the XMLVM project: the role of > a committer. A committer, just like the core team members, has commit > rights to the Subversion repository. The core team can offer a > contributor the role of committer if the contributor has proven > him-/herself over a period of time to deliver high-quality patches that > follow XMLVM coding conventions. A committer typically is responsible > for a certain module within XMLVM. Within that module, the committer can > make changes according to his or her discretion. If a change is > necessary outside that module, the modification should be done by > consulting the core team. As a good practice, major changes should be > discussed on the mailing list anyways. If a committer repeatedly > violates XMLVM coding conventions, the core team member can rescind the > commit rights. > > We would like to put these guidelines up for discussion on the mailing > list. We believe that it will help grow XMLVM as well as acknowledge and > recognize significant contributions by some developers. > > The XMLVM Core Team > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Panayotis K. <pan...@pa...> - 2011-01-10 22:16:34
|
On Jan 10, 2011, at 10:36 PM, Paul Poley wrote: > I have to admit I like you three being sorts of gatekeepers to the repository to make sure not just anything is making it in. But I also understand having only 3 people becomes more difficult as the project grows. I believe the best solution for this problem with a more flexible versioning system than SVN. It's not the first time I vote in favor of Mercurial/GIT which are able to make and handle branches and merging much easier and most of the time in an automatic manner. |
|
From: Paul P. <bay...@gm...> - 2011-01-10 22:48:14
|
You can do the same thing with subversion. It's quite easy to make branches & merge with it as well. I'm not familiar with Mercurial/GIT, but I'm assuming it's just a matter of who's familiar with what. I'm not directing this at you. Rather, you could say this about me & Mercurial/GIT, but to steal a rather famous quote: "You always fear what you don't understand" Yes, you can do automatic merging with subversion too, but that misses the point. Each merge described is a purposeful human decision or we would forget about the branches. If we think that's too much trouble or too complicated, we don't have to do branching or tagging, but I'm trying to keep quality code separated. Just because someone wrote some code doesn't mean it's worthy of trunk (myself included). So to reiterate, my thoughts are just discussion. Please feel free to give input or critique. If you have ideas/comments on Mercurial/GIT, please do share. Thanks! Paul On Mon, Jan 10, 2011 at 4:16 PM, Panayotis Katsaloulis < pan...@pa...> wrote: > > On Jan 10, 2011, at 10:36 PM, Paul Poley wrote: > > > I have to admit I like you three being sorts of gatekeepers to the > repository to make sure not just anything is making it in. But I also > understand having only 3 people becomes more difficult as the project grows. > > I believe the best solution for this problem with a more flexible > versioning system than SVN. > It's not the first time I vote in favor of Mercurial/GIT which are able to > make and handle branches and merging much easier and most of the time in an > automatic manner. > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Panayotis K. <pan...@pa...> - 2011-01-10 23:08:53
|
On Jan 11, 2011, at 12:48 AM, Paul Poley wrote: > You can do the same thing with subversion. It's quite easy to make branches & merge with it as well. I'm not familiar with Mercurial/GIT, but I'm assuming it's just a matter of who's familiar with what. I'm not directing this at you. Rather, you could say this about me & Mercurial/GIT, but to steal a rather famous quote: > "You always fear what you don't understand" > > Yes, you can do automatic merging with subversion too, but that misses the point. Each merge described is a purposeful human decision or we would forget about the branches. If we think that's too much trouble or too complicated, we don't have to do branching or tagging, but I'm trying to keep quality code separated. Just because someone wrote some code doesn't mean it's worthy of trunk (myself included). > > So to reiterate, my thoughts are just discussion. Please feel free to give input or critique. If you have ideas/comments on Mercurial/GIT, please do share. I am just talking after my own experiences. I've used SVN for a long time and I was too reluctant to move on to mercurial. But there were real advantages on using mercurial instead of SVN. What SVN actually does with branches is to copy the whole directory structure over and over again. To drop a branch or merge two branches was (in my experience) a nightmare, especially if 3-way merge was required (i.e. changes were performed on the same block of code). Moreover, other resources like binaries or files moving around were implemented by a non-optimized way; not to mention the time and internet requirements in the case someone wants to go from one version to another. Even worse, moving from one branch to another was practically moving from one project to another with nothing in common. All these problems made the whole procedure slow, bulky and not really user friendly. Distributed versioning systems have proved to solve these problems in an elegant manner. I've chosen mercurial, but this doesn't matter - any one is good. I can only say that when I went to mercurial, I couldn't go back. I've actually used a lot mercurial during the last months with XMLVM. I've created monster patches, when at the same time official XMLVM tree moved along, and resolved all merges with success. I am convinced that, without the help of mercurial this continuous merging and developing would not have been possible. |
|
From: Joshua M. <xm...@me...> - 2011-01-11 00:02:32
|
Hi all, I was recently part of a SCM discussion. In comparing distributed vs traditional source control we have basically come down to understanding that you can do exactly the same things with each. The only difference is whether their command line clients make it easy or not. Distributed SCMs seem to focus on making merges easier, traditional focus on carefully tracking what goes in to branches. Distributed seem to spend more time on their merge tools, so they seem to merge better.. Regards, -- Joshua Melcon On Mon, Jan 10, 2011 at 3:08 PM, Panayotis Katsaloulis < pan...@pa...> wrote: > > On Jan 11, 2011, at 12:48 AM, Paul Poley wrote: > > > You can do the same thing with subversion. It's quite easy to make > branches & merge with it as well. I'm not familiar with Mercurial/GIT, but > I'm assuming it's just a matter of who's familiar with what. I'm not > directing this at you. Rather, you could say this about me & Mercurial/GIT, > but to steal a rather famous quote: > > "You always fear what you don't understand" > > > > Yes, you can do automatic merging with subversion too, but that misses > the point. Each merge described is a purposeful human decision or we would > forget about the branches. If we think that's too much trouble or too > complicated, we don't have to do branching or tagging, but I'm trying to > keep quality code separated. Just because someone wrote some code doesn't > mean it's worthy of trunk (myself included). > > > > So to reiterate, my thoughts are just discussion. Please feel free to > give input or critique. If you have ideas/comments on Mercurial/GIT, please > do share. > > > I am just talking after my own experiences. > I've used SVN for a long time and I was too reluctant to move on to > mercurial. But there were real advantages on using mercurial instead of SVN. > > What SVN actually does with branches is to copy the whole directory > structure over and over again. To drop a branch or merge two branches was > (in my experience) a nightmare, especially if 3-way merge was required (i.e. > changes were performed on the same block of code). Moreover, other resources > like binaries or files moving around were implemented by a non-optimized > way; not to mention the time and internet requirements in the case someone > wants to go from one version to another. Even worse, moving from one branch > to another was practically moving from one project to another with nothing > in common. > All these problems made the whole procedure slow, bulky and not really user > friendly. > > Distributed versioning systems have proved to solve these problems in an > elegant manner. I've chosen mercurial, but this doesn't matter - any one is > good. > I can only say that when I went to mercurial, I couldn't go back. I've > actually used a lot mercurial during the last months with XMLVM. I've > created monster patches, when at the same time official XMLVM tree moved > along, and resolved all merges with success. I am convinced that, without > the help of mercurial this continuous merging and developing would not have > been possible. > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Paul P. <bay...@gm...> - 2011-01-11 17:01:25
|
Hi Panayotis, Actually subversion does not copy the entire directory for a branch. It simply makes a link to a specific tree/revision. It is very inexpensive & should never take more than a split second. I've been using subversion for not quite 5 years, so maybe there was an initial version for which this was not true? Or perhaps this was the case for CVS? Also, switching branches is very quick assuming they are common, even without many internet resources. It is not like switching to a project with nothing in common. E.g. if I had trunk checked out for a large code base, I can branch in a split second & switch to the new branch in very little time (a few seconds). This is because they are the same files & nothing needs to be rechecked out. Subversion will check the hidden ".svn" files for the revision numbers, and if up to date, it moves on. Dropping & merging is very simple as well, even if not from the same branch. E.g. I have a local copy of XMLVM & I merge official XMLVM changes into it. At my work, we generally have 10+ branches at any time, and everyone easily merges into our development branch with no trouble. Now binary file changes, I don't think I can argue with. They're probably not optimized in subversion. I will have to take your word that they are handled well in Mercurial/GIT, but I would be interested in seeing how. I would encourage you to give subversion another chance. I've had a great experience with it, and I'm surprised to hear your troubles. Perhaps you were dealing with a poorly managed repository. I'm being somewhat hypocritical though, since I can't say I have time to investigate Mercurial/GIT right now, but I'll keep it in mind. Paul On Mon, Jan 10, 2011 at 5:32 PM, Joshua Melcon <xm...@me...> wrote: > Hi all, > > I was recently part of a SCM discussion. In comparing distributed vs > traditional source control we have basically come down to understanding that > you can do exactly the same things with each. The only difference is > whether their command line clients make it easy or not. Distributed SCMs > seem to focus on making merges easier, traditional focus on carefully > tracking what goes in to branches. Distributed seem to spend more time on > their merge tools, so they seem to merge better.. > > Regards, > > -- Joshua Melcon > > > > On Mon, Jan 10, 2011 at 3:08 PM, Panayotis Katsaloulis < > pan...@pa...> wrote: > >> >> On Jan 11, 2011, at 12:48 AM, Paul Poley wrote: >> >> > You can do the same thing with subversion. It's quite easy to make >> branches & merge with it as well. I'm not familiar with Mercurial/GIT, but >> I'm assuming it's just a matter of who's familiar with what. I'm not >> directing this at you. Rather, you could say this about me & Mercurial/GIT, >> but to steal a rather famous quote: >> > "You always fear what you don't understand" >> > >> > Yes, you can do automatic merging with subversion too, but that misses >> the point. Each merge described is a purposeful human decision or we would >> forget about the branches. If we think that's too much trouble or too >> complicated, we don't have to do branching or tagging, but I'm trying to >> keep quality code separated. Just because someone wrote some code doesn't >> mean it's worthy of trunk (myself included). >> > >> > So to reiterate, my thoughts are just discussion. Please feel free to >> give input or critique. If you have ideas/comments on Mercurial/GIT, please >> do share. >> >> >> I am just talking after my own experiences. >> I've used SVN for a long time and I was too reluctant to move on to >> mercurial. But there were real advantages on using mercurial instead of SVN. >> >> What SVN actually does with branches is to copy the whole directory >> structure over and over again. To drop a branch or merge two branches was >> (in my experience) a nightmare, especially if 3-way merge was required (i.e. >> changes were performed on the same block of code). Moreover, other resources >> like binaries or files moving around were implemented by a non-optimized >> way; not to mention the time and internet requirements in the case someone >> wants to go from one version to another. Even worse, moving from one branch >> to another was practically moving from one project to another with nothing >> in common. >> All these problems made the whole procedure slow, bulky and not really >> user friendly. >> >> Distributed versioning systems have proved to solve these problems in an >> elegant manner. I've chosen mercurial, but this doesn't matter - any one is >> good. >> I can only say that when I went to mercurial, I couldn't go back. I've >> actually used a lot mercurial during the last months with XMLVM. I've >> created monster patches, when at the same time official XMLVM tree moved >> along, and resolved all merges with success. I am convinced that, without >> the help of mercurial this continuous merging and developing would not have >> been possible. >> >> ------------------------------------------------------------------------------ >> Gaining the trust of online customers is vital for the success of any >> company >> that requires sensitive data to be transmitted over the Web. Learn how >> to >> best implement a security strategy that keeps consumers' information >> secure >> and instills the confidence they need to proceed with transactions. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> xmlvm-users mailing list >> xml...@li... >> https://lists.sourceforge.net/lists/listinfo/xmlvm-users >> > > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > |
|
From: Hansi R. <su...@su...> - 2011-01-11 17:24:56
|
> Now binary file changes, I don't think I can argue with. They're probably > not optimized in subversion. I will have to take your word that they are > handled well in Mercurial/GIT, but I would be interested in seeing how. > i really (really really) dislike svn, but you can totally argue with this: http://en.wikipedia.org/wiki/Apache_Subversion#Features "Native support for binary files, with space-efficient binary-diff storage." h,- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X