You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2009/04/16 11:31:42 UTC
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
On Thu, Apr 16, 2009 at 12:55:30PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> Public svn_wc_apply_svnpatch() function still exists. Would it make
> sense to have a public function which applies unidiff parts of
> patches?
Quite possibly, yes. We can make a new one, or promote the
apply_textdiffs() function in libsvn_client/patch.c to public.
> SVN_CONFIG_OPTION_PATCH_CMD should be removed from svn_config.h.
> SVN_ERR_EXTERNAL_PROGRAM_MISSING should be removed from svn_error_codes.h.
> Definition of Wimp() at the beginning of this file should be removed.
r37301.
Thanks,
Stefan
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Edmund Wong <ed...@kdtc.net>.
Greg Stein wrote:
>> So whoever created this mailing list software, aren't aware of these
>> issues? It would do havok to those using PGP-signed messages,
>> no? (Not that I noticed a lot of these here).
>
> Oh, they (CollabNet) are aware. They have some fixes for the various
> issues, but they aren't going to be fixed until the next release
> (whenever that may be).
It's from CollabNet? Interesting.
It's a pretty interesting ML software they have. They can take
an e-mail and hold it on a mod queue and then have the mods
sending a response (allowing comments too?). Then sending
the approved message to both the mailing list and the forum.
That's a pretty cool.
With the mailer.py, if Collabnet had a nntp server, it'd be
a cool bonus. Of course, posting on the nntp server might
complicate their processes since they'd have to take the
nntp post and save it to the mailing list as well. And plus
the fact moderating nntp newsgroups is a whole different
ball game. (Read only nntp groups? Would do well for
svn and issues lists.)
>
> And yah, it would probably throw off signed messages. But as you note,
> it is very rare for somebody in an Open Source community to sign a
> message as protection against tampering. Not that useful in an open
> environment :-P
Point well taken. :)
Edmund
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1765030
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Apr 17, 2009 at 09:38, Edmund Wong <ed...@kdtc.net> wrote:
> Greg Stein wrote:
>
>>> Just a matter of curiosity and possibly a stupid question;
>>> but, why isn't there a message link at the end of your
>>> message, while there are in others?
>>
>> Who the hell knows? We have some crappy non-standard mailing list
>> software running this list. It does a lot of bizarre things that
>> mailing list software should not do. First and foremost, it should
>> pass messages intact (and maybe add some headers), but no... it
>> rewrites message content.
>>
>
> So whoever created this mailing list software, aren't aware of these
> issues? It would do havok to those using PGP-signed messages,
> no? (Not that I noticed a lot of these here).
Oh, they (CollabNet) are aware. They have some fixes for the various
issues, but they aren't going to be fixed until the next release
(whenever that may be).
And yah, it would probably throw off signed messages. But as you note,
it is very rare for somebody in an Open Source community to sign a
message as protection against tampering. Not that useful in an open
environment :-P
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1764694
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Edmund Wong <ed...@kdtc.net>.
Greg Stein wrote:
>> Just a matter of curiosity and possibly a stupid question;
>> but, why isn't there a message link at the end of your
>> message, while there are in others?
>
> Who the hell knows? We have some crappy non-standard mailing list
> software running this list. It does a lot of bizarre things that
> mailing list software should not do. First and foremost, it should
> pass messages intact (and maybe add some headers), but no... it
> rewrites message content.
>
So whoever created this mailing list software, aren't aware of these
issues? It would do havok to those using PGP-signed messages,
no? (Not that I noticed a lot of these here).
Edmund
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1763128
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Apr 16, 2009 at 14:25, Edmund Wong <ed...@kdtc.net> wrote:
> Stefan Sperling wrote:
>> On Thu, Apr 16, 2009 at 12:31:42PM +0100, Stefan Sperling wrote:
>>> On Thu, Apr 16, 2009 at 12:55:30PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
>>>> Public svn_wc_apply_svnpatch() function still exists. Would it make
>>>> sense to have a public function which applies unidiff parts of
>>>> patches?
>>> Quite possibly, yes. We can make a new one, or promote the
>>> apply_textdiffs() function in libsvn_client/patch.c to public.
>>
>> On second thought, one public function should be enough.
>> It should accept both svnpatches or unidiffs, and do the right thing
>> for each.
>>
>> Stefan
>>
>
> Hi,
>
> Just a matter of curiosity and possibly a stupid question;
> but, why isn't there a message link at the end of your
> message, while there are in others?
Who the hell knows? We have some crappy non-standard mailing list
software running this list. It does a lot of bizarre things that
mailing list software should not do. First and foremost, it should
pass messages intact (and maybe add some headers), but no... it
rewrites message content.
Sigh.
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1746565
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Edmund Wong <ed...@kdtc.net>.
Stefan Sperling wrote:
> On Thu, Apr 16, 2009 at 12:31:42PM +0100, Stefan Sperling wrote:
>> On Thu, Apr 16, 2009 at 12:55:30PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
>>> Public svn_wc_apply_svnpatch() function still exists. Would it make
>>> sense to have a public function which applies unidiff parts of
>>> patches?
>> Quite possibly, yes. We can make a new one, or promote the
>> apply_textdiffs() function in libsvn_client/patch.c to public.
>
> On second thought, one public function should be enough.
> It should accept both svnpatches or unidiffs, and do the right thing
> for each.
>
> Stefan
>
Hi,
Just a matter of curiosity and possibly a stupid question;
but, why isn't there a message link at the end of your
message, while there are in others?
Edmund
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1746415
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Apr 16, 2009 at 13:53, Arfrever Frehtes Taifersar Arahesis
<Ar...@gmail.com> wrote:
> 2009-04-16 13:33 Stefan Sperling <st...@elego.de> napisał(a):
>> On Thu, Apr 16, 2009 at 12:31:42PM +0100, Stefan Sperling wrote:
>>> On Thu, Apr 16, 2009 at 12:55:30PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
>>> > Public svn_wc_apply_svnpatch() function still exists. Would it make
>>> > sense to have a public function which applies unidiff parts of
>>> > patches?
>>>
>>> Quite possibly, yes. We can make a new one, or promote the
>>> apply_textdiffs() function in libsvn_client/patch.c to public.
>
> So the code which applies unidiff parts of patches is in libsvn_client,
> while the code which applies SVNPATCH1 blocks is in libsvn_wc?
> If yes, is this discrepancy intentional?
Certainly not. It is crappy code organization left over from the merge.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1746110
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Arfrever Frehtes Taifersar Arahesis <Ar...@GMail.Com>.
2009-04-16 13:33 Stefan Sperling <st...@elego.de> napisał(a):
> On Thu, Apr 16, 2009 at 12:31:42PM +0100, Stefan Sperling wrote:
>> On Thu, Apr 16, 2009 at 12:55:30PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
>> > Public svn_wc_apply_svnpatch() function still exists. Would it make
>> > sense to have a public function which applies unidiff parts of
>> > patches?
>>
>> Quite possibly, yes. We can make a new one, or promote the
>> apply_textdiffs() function in libsvn_client/patch.c to public.
So the code which applies unidiff parts of patches is in libsvn_client,
while the code which applies SVNPATCH1 blocks is in libsvn_wc?
If yes, is this discrepancy intentional?
> On second thought, one public function should be enough.
> It should accept both svnpatches or unidiffs, and do the right thing
> for each.
+1.
--
Arfrever Frehtes Taifersar Arahesis
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1745936
Re: svn commit: r37294 - in trunk/subversion: include libsvn_client
libsvn_wc tests/cmdline tests/cmdline/svntest
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Apr 16, 2009 at 12:31:42PM +0100, Stefan Sperling wrote:
> On Thu, Apr 16, 2009 at 12:55:30PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> > Public svn_wc_apply_svnpatch() function still exists. Would it make
> > sense to have a public function which applies unidiff parts of
> > patches?
>
> Quite possibly, yes. We can make a new one, or promote the
> apply_textdiffs() function in libsvn_client/patch.c to public.
On second thought, one public function should be enough.
It should accept both svnpatches or unidiffs, and do the right thing
for each.
Stefan