El lun, 28-07-2008 a las 11:10 +0100, Ian Boston escribió:
> On 28 Jul 2008, at 00:43, Nicolaas Matthijs (JIRA) wrote:
>
> > On Mon, Jul 28, 2008 at 12:02 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
> >>
> >> Question as a git user, also generating patches that others might
> >> want to
> >> check.
> >>
> >> Is there a way of generating svn patches using git, or do we have
> >> to hand
> >> edit the git patches to match
> >> patch -p0 < patchfile
> >>
> >> git-svn doesnt have a diff option, probably because git is patch
> >> based
> >> system.
> >>
> >
> > I have never had problems applying git generated patches into a svn
> > working copy
> >
>
>
>
> Me neither :)
>
> > -p1 is typically the default for any diff. It assumes that the diff
> > was generated one step "backwards" from the files, i.e. it would start
> > by shindig/resources/... instead of resources/...
> >
> > The only problem with git-generated patches that I've seen is that the
> > use of some options (I seem to recall -M or -C to detect moves or
> > copies) will generate a format richer in informaction that is not
> > parseable for svn (or for any patch tool except git's, for what
> > matter).
>
> Do you happen to know if other patch tools ignore the information or
> barf on the format ?
>
> I had thought that patch searched for --- +++ and then processed the
> patch according to the line offsets, and if the patch ran out it
> would continue searching for the next --- +++
>
> A git diff header
>
> diff --git a/site/checkstyle.xml b/site/checkstyle.xml
> new file mode 100644
> index 0000000..fb5bf45
> --- /dev/null
> +++ b/site/checkstyle.xml
>
I think this one works, other tools correctly ignore this extra info.
What would fail is something that talks about moved or copied files. For
instance, in my copy, r679434, with -M -C, is shown as:
diff --git
a/java/social-api/src/main/java/org/apache/shindig/social/core/util/B
eanConverter.java
b/java/social-api/src/main/java/org/apache/shindig/social/open
social/service/BeanConverter.java
similarity index 94%
rename from
java/social-api/src/main/java/org/apache/shindig/social/core/util/BeanConverter.java
rename to
java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/BeanConverter.java
index 6fb7463..13c9bca 100644
---
a/java/social-api/src/main/java/org/apache/shindig/social/core/util/BeanConverter.java
+++
b/java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/BeanConverter.java
@@ -15,7 +15,7 @@
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations under the
License.
*/
-package org.apache.shindig.social.core.util;
+package org.apache.shindig.social.opensocial.service;
public interface BeanConverter {
<T> T convertToObject(String string, Class<T> className);
This is actually very handy for people, as only the package name has
changed in the file, and a person doing a code audit can see fast that
this is the only change for the file. Most other tools would instead
list this change as a delete and addition, and a person inspecting it
would need to diff manually the file before-after or to look painfully
through all the code lines. For this example, two files changed, 24
lines deleted, 24 lines added vs one file changed, one insertion, one
deletion. And this is just a tiny file moved.
subversion would apply this patch on the destination (which does not
exist), and thus fail.
This is the reason why, when I did a big refactoring with little real
content I presented two different sets of patches, for humans and for
robots: the one for humans was way easier to read, the other one was the
only one that patch or svn would apply. The one for humans was like 1/3
in number of lines from the one that included moves as delete-add pairs.
For a bigger example, the SHINDIG-467 change (r679055) has those two
different patches, with and without move detection:
91 files changed, 336 insertions(+), 182 deletions(-)
157 files changed, 7633 insertions(+), 7479 deletions(-)
Think about this for a code inspection, I'm not sure if people is using
better tools for this, but for me it is really great to make sure no
extraneous changes sneaked into a refactoring.
Regargs
Santiago
> A svn diff header
>
>
> Index: site/checkstyle.xml
> ===================================================================
> --- site/checkstyle.xml (revision 49418)
> +++ site/checkstyle.xml (working copy)
>
>
> (BTW, I am trying to understand the requirements for patches, I hope
> I am not being difficult)
> Ian
>
>
> >
> > Regards
> > Santiago
> >
> >>
> >> ( I am happy to try patch -p1 if patch -p0 doesn't work, but I
> >> want to what
> >> generates least work for everyone, but I don't really want to have
> >> to go
> >> searching the tree much for the diff root more than that)
> >>
> >> Ian
> >>
> >>
> >> On 25 Jul 2008, at 16:40, Cassie wrote:
> >>
> >>> Yup - the patch you generated has git stuff in it, so I'm
> >>> guessing thats
> >>> why
> >>> it works for you.
> >>> I put the details of how to generate non git patches on your
> >>> first jira
> >>> issue but you can also find the info here:
> >>>
> >>> http://incubator.apache.org/shindig/#creatingPatches
> >>>
> >>> Thanks!
> >>>
> >>> - Cassie
> >>>
> >>>
> >>> On Fri, Jul 25, 2008 at 8:48 AM, Nicolaas Matthijs <
> >>> [EMAIL PROTECTED]> wrote:
> >>>
> >>>> Hi Cassie,
> >>>> I just tried to apply my patch on a clean svn checkout, and it
> >>>> works if
> >>>> you
> >>>> use
> >>>> patch -p1 < "mypatch". This probably happens because I'm using git.
> >>>>
> >>>> Should I be adjusting my patches?
> >>>>
> >>>> Thanks,
> >>>> Nicolaas
> >>>>
> >>>> On Fri, Jul 25, 2008 at 4:05 PM, Cassie <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Nicolass - improving the sample container to be more "real" is
> >>>>> definitely
> >>>>> on
> >>>>> our list of things to do. Like Ropu mentioned we also want to
> >>>>> add social
> >>>>> based features, but I think adding things like drag and drop
> >>>>> and real
> >>>>
> >>>> prefs
> >>>>>
> >>>>> etc is also a great place to start.
> >>>>>
> >>>>> I definitely don't think the code should go all into the same
> >>>>> file :)
> >>>>> but
> >>>>> using the samplecontainer directory for all of the code makes
> >>>>> sense.
> >>>>>
> >>>>> As for your patches, I was going to get those in today but they
> >>>>> are in a
> >>>>> slightly incorrect format. ie patch -p0 < "your patch file"
> >>>>> doesn't
> >>>>> work.
> >>>>
> >>>> I
> >>>>>
> >>>>> updated the first jira issue with some quick instructions. Once
> >>>>> you
> >>>>
> >>>> follow
> >>>>>
> >>>>> those then hopefully I'll be able to patch away!
> >>>>>
> >>>>> Thanks for your help.
> >>>>> - Cassie
> >>>>>
> >>>>>
> >>>>> On Fri, Jul 25, 2008 at 7:24 AM, Ropu <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>> Hte issue with that is that iGoogle is a Gadget render, and is
> >>>>>> not
> >>>>
> >>>> using
> >>>>>>
> >>>>>> the
> >>>>>> social layer of opensocial
> >>>>>>
> >>>>>> so for that you will need to add friends, activities, persistence
> >>>>
> >>>> layer.
> >>>>>>
> >>>>>> so it should be more like a orkuy or hi5 that iGoogle.
> >>>>>>
> >>>>>> still we have the partuza, a simple social network that has
> >>>>>> all the
> >>>>>
> >>>>> social
> >>>>>>
> >>>>>> stuff ready to work with shindig
> >>>>>>
> >>>>>> the only thing is that is coded in PHP :D
> >>>>>>
> >>>>>> hope this helps
> >>>>>>
> >>>>>> ropu
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 25, 2008 at 10:56 AM, Nicolaas Matthijs <
> >>>>>> [EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>> I would like to introduce an iGoogle like portal into
> >>>>>>> Shindig, which
> >>>>>>
> >>>>>> allows
> >>>>>>>
> >>>>>>> you to add multiple widgets in different columns and which
> >>>>>>> allows
> >>>>>>> to drag them around with the state being saved in a cookie. I
> >>>>>>> would
> >>>>>
> >>>>> like
> >>>>>>
> >>>>>> to
> >>>>>>>
> >>>>>>> do this for 2 reasons:
> >>>>>>>
> >>>>>>> 1) I've seen several requests for this type of functionality
> >>>>>>> passing
> >>>>
> >>>> on
> >>>>>>
> >>>>>> the
> >>>>>>>
> >>>>>>> list
> >>>>>>> 2) I think it might increase uptake of Shindig if people can
> >>>>>>> see what
> >>>>>
> >>>>> can
> >>>>>>>
> >>>>>>> be achieved with it
> >>>>>>>
> >>>>>>> So my first question is whether you think this is a good
> >>>>>>> idea. My
> >>>>>
> >>>>> second
> >>>>>>>
> >>>>>>> question is where you
> >>>>>>> think this should go. Should it go as a (big) modification to
> >>>>>>> the
> >>>>>>> samplecontainer, which is perfectly
> >>>>>>> possible, or should it go in as a separate file in examples?
> >>>>>>>
> >>>>>>> P.S.: I've done 3 patches for the samplecontainer already.
> >>>>>>> How long
> >>>>>
> >>>>> does
> >>>>>>
> >>>>>> it
> >>>>>>>
> >>>>>>> normally take
> >>>>>>> to get an evaluation of those?
> >>>>>>>
> >>>>>>> Thanks in advance,
> >>>>>>> Nicolaas
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> .-. --- .--. ..-
> >>>>>> R o p u
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
--
Santiago Gala
http://memojo.com/~sgala/blog/
