I suggest we change the process for submitting patches to the following: - have a directory writable by everyone such as IMP/patch - to submit a patch, foo, check in trunk/patch/foo.patch and truck/ patch/foo.readme with the patch and a description, respectively - send a short email to imp-dev - when Ben commits the patch, he removes the files from SVN
The advantage of this system is: - it is easy to see keep track of what patches have been submitted but not committed. - it is easy to update patches that have been submitted but not yet committed - it is easy to apply patches that have not yet been committed to your copy of IMP, so is is less problematic when patches don't get committed for a long time. - no more having to get files to your email - all the submitted patches are listed in one place for ben to see - the submitted doesn't have to manually clean how his records of the patch when Ben submits it.
Anyone have improvements? I'll try out such a system with my next patch.
I also think this is a good idea
Daniel Russel wrote: > I suggest we change the process for submitting patches to the following: > - have a directory writable by everyone such as IMP/patch > - to submit a patch, foo, check in trunk/patch/foo.patch and > truck/patch/foo.readme with the patch and a description, respectively > - send a short email to imp-dev > - when Ben commits the patch, he removes the files from SVN > > The advantage of this system is: > - it is easy to see keep track of what patches have been submitted but > not committed. > - it is easy to update patches that have been submitted but not yet > committed > - it is easy to apply patches that have not yet been committed to your > copy of IMP, so is is less problematic when patches don't get > committed for a long time. > - no more having to get files to your email > - all the submitted patches are listed in one place for ben to see > - the submitted doesn't have to manually clean how his records of the > patch when Ben submits it. > > Anyone have improvements? I'll try out such a system with my next patch. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
sounds very good.
On Dec 12, 2008, at 4:54 AM, Daniel Russel wrote:
> I suggest we change the process for submitting patches to the > following: > - have a directory writable by everyone such as IMP/patch > - to submit a patch, foo, check in trunk/patch/foo.patch and truck/ > patch/foo.readme with the patch and a description, respectively > - send a short email to imp-dev > - when Ben commits the patch, he removes the files from SVN > > The advantage of this system is: > - it is easy to see keep track of what patches have been submitted > but not committed. > - it is easy to update patches that have been submitted but not yet > committed > - it is easy to apply patches that have not yet been committed to > your copy of IMP, so is is less problematic when patches don't get > committed for a long time. > - no more having to get files to your email > - all the submitted patches are listed in one place for ben to see > - the submitted doesn't have to manually clean how his records of > the patch when Ben submits it. > > Anyone have improvements? I'll try out such a system with my next > patch. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
I stuck the outstanding patches I know of in kernel/doc/patch.
How does one apply a patch generated by svn which involved moving files? Taking the diff and then using patch doesn't seem to do the right thing. Or is the system just broken for such changes?
On Dec 11, 2008, at 8:07 PM, Seung Joong Kim wrote:
> I also think this is a good idea > > Daniel Russel wrote: >> I suggest we change the process for submitting patches to the >> following: >> - have a directory writable by everyone such as IMP/patch >> - to submit a patch, foo, check in trunk/patch/foo.patch and truck/ >> patch/foo.readme with the patch and a description, respectively >> - send a short email to imp-dev >> - when Ben commits the patch, he removes the files from SVN >> >> The advantage of this system is: >> - it is easy to see keep track of what patches have been submitted >> but not committed. >> - it is easy to update patches that have been submitted but not yet >> committed >> - it is easy to apply patches that have not yet been committed to >> your copy of IMP, so is is less problematic when patches don't get >> committed for a long time. >> - no more having to get files to your email >> - all the submitted patches are listed in one place for ben to see >> - the submitted doesn't have to manually clean how his records of >> the patch when Ben submits it. >> >> Anyone have improvements? I'll try out such a system with my next >> patch. >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Hi,
It looks like I don't have permissions to commit into this patch folder. so I attached my patch that computes distance between two vectors. and I would be very happy to have the permissions to commit there.
Dina
On Fri, Dec 12, 2008 at 2:25 PM, Daniel Russel drussel@gmail.com wrote:
> I stuck the outstanding patches I know of in kernel/doc/patch. > > How does one apply a patch generated by svn which involved moving files? > Taking the diff and then using patch doesn't seem to do the right thing. Or > is the system just broken for such changes? > > > > On Dec 11, 2008, at 8:07 PM, Seung Joong Kim wrote: > > I also think this is a good idea >> >> Daniel Russel wrote: >> >>> I suggest we change the process for submitting patches to the following: >>> - have a directory writable by everyone such as IMP/patch >>> - to submit a patch, foo, check in trunk/patch/foo.patch and >>> truck/patch/foo.readme with the patch and a description, respectively >>> - send a short email to imp-dev >>> - when Ben commits the patch, he removes the files from SVN >>> >>> The advantage of this system is: >>> - it is easy to see keep track of what patches have been submitted but >>> not committed. >>> - it is easy to update patches that have been submitted but not yet >>> committed >>> - it is easy to apply patches that have not yet been committed to your >>> copy of IMP, so is is less problematic when patches don't get committed for >>> a long time. >>> - no more having to get files to your email >>> - all the submitted patches are listed in one place for ben to see >>> - the submitted doesn't have to manually clean how his records of the >>> patch when Ben submits it. >>> >>> Anyone have improvements? I'll try out such a system with my next patch. >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
Dina Schneidman wrote: > It looks like I don't have permissions to commit into this patch folder.
Right - because currently it lives under kernel/doc, which you don't have write permissions for. I will move it somewhere with less restrictive permissions.
> so I attached my patch that computes distance between two vectors.
I don't think VectorD is the best place for such methods, since vectors are designed primarily for use as distances, not as points, hence the presence of distance-like methods such as the scalar product. However, there are a couple of places in the code where Vectors are used to represent points. Perhaps a separate Point class would be a cleaner interface though. Opinions?
Ben
the thing is that the Point will need the same functions as the Vector has and sometimes you have to move the Point in the Vector direction, so they need to interact anyway.
On Mon, Dec 22, 2008 at 12:47 PM, Ben Webb ben@salilab.org wrote:
> Dina Schneidman wrote: > > It looks like I don't have permissions to commit into this patch folder. > > Right - because currently it lives under kernel/doc, which you don't > have write permissions for. I will move it somewhere with less > restrictive permissions. > > > so I attached my patch that computes distance between two vectors. > > I don't think VectorD is the best place for such methods, since vectors > are designed primarily for use as distances, not as points, hence the > presence of distance-like methods such as the scalar product. However, > there are a couple of places in the code where Vectors are used to > represent points. Perhaps a separate Point class would be a cleaner > interface though. Opinions? > > Ben > -- > ben@salilab.org http://salilab.org/~ben/http://salilab.org/%7Eben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
Dina Schneidman wrote: > the thing is that the Point will need the same functions as the Vector > has and sometimes you have to move the Point in the Vector direction, so > they need to interact anyway.
Very well - I think it would be too complicated to split them out anyway. I'll stick your patch in and write some simple unit tests for it. (If you can get in the habit of writing tests to accompany new functionality, that'd be great.)
Ben
> > I don't think VectorD is the best place for such methods, since vectors > are designed primarily for use as distances, not as points, hence the > presence of distance-like methods such as the scalar product. However, > there are a couple of places in the code where Vectors are used to > represent points. Perhaps a separate Point class would be a cleaner > interface though. Opinions? > I do like having separate Point and Vector classes, but would require someone to to do it :-)
theoretically I like the separation too, but from the practical viewpoint, I'm not sure it's worth the effort.
On Mon, Dec 22, 2008 at 1:13 PM, Daniel Russel drussel@gmail.com wrote:
> > >> I don't think VectorD is the best place for such methods, since vectors >> are designed primarily for use as distances, not as points, hence the >> presence of distance-like methods such as the scalar product. However, >> there are a couple of places in the code where Vectors are used to >> represent points. Perhaps a separate Point class would be a cleaner >> interface though. Opinions? >> >> > I do like having separate Point and Vector classes, but would require > someone to to do it :-) > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
-
Ben Webb -
Daniel Russel -
Dina Schneidman -
Keren Lasker -
Seung Joong Kim