On Tuesday 27 November 2012 11:52 PM, Julian Foad wrote:
vijay wrote:
This updated patch has all the changes.
I have removed some redundant portion of code in print_dirent() and
print_dirent_xml() in svn/list-cmd.c.
Thanks Vijay. That looks great. I've committed it in r1414304. Nice log
Johan Corveleyn wrote:
> On Sun, Nov 11, 2012 at 1:59 PM, Stefan Fuhrmann wrote:
>> On Thu, Nov 8, 2012 at 6:04 PM, Julian Foad wrote:
>>> Stefan Fuhrmann wrote:
But I did run across an assertion in mergeinfo.c, :line 1174
> during merge_tests.py 125:
>>
>> SVN_ERR_ASSERT_NO_RETU
[Peter Samuelson]
> If the "misspelled" property exists, probably the user already noticed
> the typo, that's why they're deleting it! I see no need for --force
> here.
>
> If the "misspelled" property does not exist, I think the warning that
> the property does not exist is just as good as a wa
vijay wrote:
> This updated patch has all the changes.
>
> I have removed some redundant portion of code in print_dirent() and
> print_dirent_xml() in svn/list-cmd.c.
Thanks Vijay. That looks great. I've committed it in r1414304. Nice log
message by the way.
- Julian
Greg Stein wrote:
> Eh? So it already has a separate/different semantic?
No, it already had near-enough the same semantics: "allow property values that
this client thinks are invalid". This just extends it to mean "allow property
values *and names* that ...".
- Julian
> Yay.
> Bert Huijben
Markus Schaber wrote:
> Currently, we have special revisions "WORKING", "HEAD",
> "BASE", "COMMITTED", "PREV" which can be used
> internally in the API, as well as for "svn cat".
>
> What about defining additional special revisions for conflicted files, like
> "OLDER" and "INCOMING"?
>
> This
On 11/27/2012 06:55 AM, sebb wrote:
> Are there any plans to support an "rmdir" action?
None that I'm aware of.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
On Tue, Nov 27, 2012 at 9:21 AM, Daniel Shahaf wrote:
> Hyrum K Wright wrote on Tue, Nov 27, 2012 at 09:11:50 -0500:
> > On Tue, Nov 27, 2012 at 9:07 AM, Daniel Shahaf >wrote:
> >
> > > Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> > > > Instead, I propose subdirectories named ev
Thanks for the reply.
So I spent ages digging into this (and related issues) last night, and
that is correct. gethostbyname() is indeed failing, spontaneously it
seems. However, as to why, I don't know yet. I'm suspecting something is
getting messed up in the local memory space that is affecting i
Hyrum K Wright wrote on Tue, Nov 27, 2012 at 09:11:50 -0500:
> On Tue, Nov 27, 2012 at 9:07 AM, Daniel Shahaf wrote:
>
> > Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> > > Instead, I propose subdirectories named ev2 in the various libsvn_foo
> > > directories which would hold Ev2
Robert Turner wrote on Mon, Nov 26, 2012 at 19:49:35 +:
> I'm in the process of making some updates to a FUSE svnfs, and while the
> process is merrily chugging away pulling file information, it starts getting
> lots of errors from the svn_client commands (not just the one below, but
> that'
On Tue, Nov 27, 2012 at 9:07 AM, Daniel Shahaf wrote:
> Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> > Instead, I propose subdirectories named ev2 in the various libsvn_foo
> > directories which would hold Ev2 implementations. They would eventually
> go
>
> Not objected to subdi
Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> Instead, I propose subdirectories named ev2 in the various libsvn_foo
> directories which would hold Ev2 implementations. They would eventually go
Not objected to subdirs, but have you considered just naming your files
libsvn_repos/ev
On 11/26/2012 06:38 PM, Peter Samuelson wrote:
>
> [Julian Foad]
>> In general, setting *or* deleting an unknown prop name causes nothing
>> significant to happen on *this* client, and may cause something
>> (expected or unexpected) to happen on another client.
>
> I don't get why we would want '
Greetings all!
r1413184 introduced the --enable-ev2-impl flag to configure on trunk to
allow interested users to compile with the Ev2 implementations of various
operations. While the set of things that supports Ev2 is not nearly
complete, it is (slowly) growing, and I'd like to do that developmen
Are there any plans to support an "rmdir" action?
This would be different from "rm", in that it would only work on
directories, and would only succeed if the directory was empty.
The "rmdir" action would be very useful in automating parts of the ASF
svnpubsub process.
E.g. where a known set of f
Eh? So it already has a separate/different semantic?
Yay.
On Nov 27, 2012 4:11 AM, "Bert Huijben" wrote:
> In this case I think the answer is easier than in most similar cases: We
> already support --force on propset in older Subversion versions.
>
> (At least that is why I didn’t ask that speci
Thanks Julian.
This updated patch has all the changes.
I have removed some redundant portion of code in print_dirent() and
print_dirent_xml() in svn/list-cmd.c.
Thanks & Regards,
Vijayaguru
On Tuesday 27 November 2012 03:19 AM, Julian Foad wrote:
vijay wrote:
On Tuesday 13 November 2012
In this case I think the answer is easier than in most similar cases: We
already support --force on propset in older Subversion versions.
(At least that is why I didn’t ask that specific question)
Bert
*From:* Greg Stein
*Sent:* November 27, 2012 9:11 AM
*To:* Julian Foad ,Branko Čib
Brane has done some excellent work here. But it seems nobody has asked
the question: why --force instead of (say) --allow-propname ?
Haven't we already decided that --force is horribly overloaded, and
horribly undefined?
Thx,
-g
On Sun, Nov 18, 2012 at 9:50 PM, Julian Foad wrote:
> 'svn propset
20 matches
Mail list logo