James Keenan wrote: >> Why are these two changes tied together? Surely if you have a capable >> feature branching system this is not necessary. > I submitted individual patches and new files last week for the > refactoring of ops2c.pl. Following the instructions in docs/ > submission.pod, I edited MANIFEST to include the new files and paths. > > Those patches and new files haven't been reviewed yet. When I went > to my next round of submissions, I wanted to get it done quickly > (I've been dealing with eye infections the last several days and am > tiring easily) and decided to submit a single patch. The MANIFEST > had entries for both submissions. >
Mixing things together is everything that you are attempting to resolve. Why are you making excuses for not achieving this? > It's not novel with me. I solicited advice on Perlmonks (http:// > perlmonks.org/?node_id=597867) on how to synchronize a Subversion > branch with trunk. The scripts I wrote implemented one of the > options described in that Perlmonks thread, which was provided from a > fellow Perl hacker who has never steered me wrong. > Sorry. Of the four first responses to that thread, you picked the one with the worst advice. > My main point is this: At this point in Parrot's development, a lot > more of that development should be going on in branches rather than > in direct commits to trunk. People need tools to manager branches > effectively and, AFAICT, no one else had addressed this problem. > particle asked me to come up with something that would reflect my > experience so far with branches and that other people would find > useful. The four files I've submitted represent my attempt to > respond to particle's request. > > I freely concede that what I've submitted is a hack -- and have so > conceded in the documentation. Perhaps what we should provide our > fellow Parrot hackers is a menu of choices for how to manage > branches. If so, then instead of my suggestion of lib/Parrot/ > Subversion/, we should have lib/Parrot/VersionControl: a directory > which would enable people to manage branches in the Parrot repository > (a) in a variety of ways using Subversion as their client; and/or (b) > using other clients such as svk. If you would like to code up such a > tool (either (a) or (b)), then code away! After all, (i) these are > just developers' tools; they're not essential to Parrot itself; (ii) > this is Perl: TIMTOWTDI. > I appreciate that, but with all due respect this system is unworkable and needs addressing - somebody would come along later, decypher the ad-hoc system that you or your advisors have invented and convert it to something standard. > If we took that approach, then we could accommodate a variety of ways > to manage branches in our repository, all with the goal of getting > people to develop more in branches. > I agree with this goal. Sam.
