On Wed, Jun 18, 2025 at 6:17 PM Branko Čibej wrote:
> As the saying goes: dammit, Mike, not you again! :D
>
Yeah, you know, I just creep out my storage container once in a while to
see if grandpa can still be of some use in the world. Happy to have helped.
Disclaimer: I haven't looked at this codebase in a really long time.
But this code in cmdline.c reads differently than my now-naive eyes would
expect:
/* If neither --non-interactive nor --force-interactive was passed,
* be interactive if stdin is a terminal.
* If --force-interactive w
On Tue, Jan 28, 2025 at 10:51 AM Nathan Hartman
wrote:
> >From time to time we get account requests for Jira from members of the
> community. There is such a request now.
>
> Historically we have declined these Jira account requests and directed
> requesters to discuss their issues at the mailing
On Thu, Jun 6, 2024 at 9:25 AM Nathan Hartman
wrote:
> I haven't had a chance to really study this yet (or build or test),
> but the main part of the patch is in ra.c, where
> svn_client__get_youngest_common_ancestor() was calling
> svn_client__get_history_as_mergeinfo(). The patch wraps those ca
On Mon, May 22, 2023 at 2:56 PM Daniel Sahlberg
wrote:
> Hi,
>
> As you all probably know Subversion was initially started by CollabNet and
> several high profile committers have worked there (and some still do).
> However the company's interest in Subversion has decreased over the years
> with s
Was totally surprised while listening to the Corecursive podcast tonight to
hear our old "migrate to git" April Fool's joke listed as a good one. See
https://pca.st/episode/8ca16af6-53c4-4a8f-b879-63988abc1232, starting
around 28:30.
--
Sent via mobile. Please excuse brevity.
Some time ago, I was doing something similar, Mark. If anything from
https://github.com/cmpilato/subversion-dist can be useful to you, feel free
to use it.
On Tue, Mar 29, 2022 at 10:07 AM Mark Phippard wrote:
> If anyone is interested in looking at what I have been doing to run
> the SVN RM pr
WARNING: This is a *total* drive-by post as I skim the thread.
Are there any svn:auto-props syntaxes that are legal .ini but not legal for
auto-props? I'm thinking of the use of a forward slash character. Could
the format be extended such that a key/propname under the [auto-props]
section that
On Sat, Jul 31, 2021 at 8:16 PM Karl Fogel wrote:
> The use case I started with is:
>
> "Check out a sparse tree, and then check out individual files --
> some of them maybe large binary blobs, others maybe smaller --
> where you need them. In many cases, one will simply go into a
> particular d
On Sat, Jun 26, 2021 at 5:12 PM Daniel Sahlberg
wrote:
> Mentioning red-bean.com, it seems that svnbook.red-bean.com doesn't
> support https. I've reached out to Fitz (since I've been in touch with him
> previously) but if someone else read this and pick it up I think it would
> be a good thing.
On Wed, Jun 2, 2021 at 8:20 AM Stefan Sperling wrote:
> ther diff implementations limit the effort spent by aborting after a
> certain number of search iterations, and then simply use the valid
> traversal which was most recently discovered. The libxdiff code used by Git
> does this, as does the
9, 2020 at 10:05 PM Yasuhito FUTATSUKI
wrote:
> On 2020/09/30 10:08, Yasuhito FUTATSUKI wrote:
> > On 2020/09/30 8:51, C. Michael Pilato wrote:
> >> Thanks for the reply. And I see what you're trying to do there, but in
> >> practice it doesn't seem to work. The
ing this construct:
-fs.repos = repos
> +fs.__dict__['repos'] = repos
...and that avoids the AttributeError, but alas the code still SEGFAULTs.
I'm attaching a(n edited for readability) log from a gdb session.
-- Mike
On Tue, Sep 29, 2020 at 4:01 PM Yasuhito FUTATSUKI
wrote
enerator(sys.argv[1], peg_revision, sys.argv[2], pool)
> print(b''.join(generator).decode('utf-8'))
On Tue, Sep 29, 2020 at 9:26 AM C. Michael Pilato
wrote:
> Hey, all. I'm wondering if I can get some extra eyes/brains on a
> particular usage of our Python bind
Hey, all. I'm wondering if I can get some extra eyes/brains on a
particular usage of our Python bindings.
The attached tarball contains a directory in which lives two files:
- run-test.sh - a shell script to drive the reproduction recipe
- pysvnget - a Python program that uses the bindings
On Fri, Aug 21, 2020 at 7:10 AM Daniel Shahaf
wrote:
> C. Michael Pilato wrote on Tue, 18 Aug 2020 10:23 -0400:
> > Sendingsubversion/bindings/swig/include/svn_types.swg
> > Sending
> subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
> > Sending
&g
/swig/svn_repos.i
Transmitting file data .done
Committing transaction...
Committed revision 1880967.
I made only minor comment/formatting changes.
On Sun, Aug 2, 2020 at 9:36 AM Yasuhito FUTATSUKI
wrote:
> On 2020/07/31 10:19, Yasuhito FUTATSUKI wrote:
> > On 2020/07/30 22:20, C
t;). But as a concept,
I'd say this part works well.
Does this change anything about the svn_fs_commit_txn() interface?
-- Mike
On Thu, Jul 30, 2020 at 5:00 AM Yasuhito FUTATSUKI
wrote:
> On 2020/07/30 17:47, Yasuhito FUTATSUKI wrote:
> > On 2020/07/29 23:43, C. Michael Pilato wrote
020/07/28 23:34, C. Michael Pilato wrote:
> >>> Hey, all.
> >>>
> >>> I'm writing some code that performs commits via the Subversion Python
> >>> bindings, and I'm struggling to understand some things I see t
Hey, all.
I'm writing some code that performs commits via the Subversion Python
bindings, and I'm struggling to understand some things I see there.
In the svn_fs.i interface file, there's this block of code:
/* ---
Fix the re
On Wed, Jul 8, 2020 at 9:37 AM Daniel Sahlberg
wrote:
> In the original email, I made note of two more pages that I didn't include
> in the patch. Do you have any insight into these or do we need to wait for
> someone else to step in?
>
Sorry, I have nothing to offer on those questions.
>
Sahlberg
wrote:
> Den ons 8 juli 2020 kl 14:34 skrev C. Michael Pilato <
> cmpil...@red-bean.com>:
>
>> Thanks, Daniel. Your patch submission is fine, though I suspect that if
>> in the future you name your patch file such that it ends with ".txt",
>> (evi
On Tue, Jul 7, 2020 at 5:38 PM Daniel Sahlberg
wrote:
> Hi,
>
> I've looked through the website and I propose a few administrative
> changes. It's my first patch so fingers crossed I have not messed up!
>
Thanks, Daniel. Your patch submission is fine, though I suspect that if in
the future you
On Mon, Jun 15, 2020 at 10:32 AM Yasuhito FUTATSUKI
wrote:
> On 2020/06/15 21:38, C. Michael Pilato wrote:
> Is it needed something like this?
>
> [[[
> Index: tools/backup/hot-backup.py.in
> ===
> --- tools/ba
Reviewed, tested, and compared with similar Python3 conversions to other
scripts. All looks good, so committed it:
Sendingbackup/hot-backup.py.in
Transmitting file data .done
Committing transaction...
Committed revision 1878855.
On Mon, Jun 15, 2020 at 4:52 AM Petyovský Petr
wrote:
> H
On 09/05/2018 04:49 PM, Mark Phippard wrote:
Assuming the PMC wanted it, is it possible for the book to be
contributed to this project and hosted in the Apache SVN repository?
Many people seem to post questions and issues in these mailing lists
as if it is part of the project anyway so maybe we
On 09/05/2018 04:10 PM, Daniel Shahaf wrote:
Can we identify specific tasks that interested volunteers can pick up?
Initial draft:
- Respond to bug reports as they come in
- Liaise with translators
- Add content about from the <1.8/1.9/1.10/1.11> release
- Bring the book up-to-speed with _all_
Hello, all!
It's been a long while since I interacted with any degree of regularity
with this community, and I've had to come to terms with some essential
truths.
First, my time as an active Subversion developer has *definitely*
passed. Oh, I may get a chance to return to it at some point i
On 08/23/2018 09:52 AM, Daniel Shahaf wrote:
We also have a subversion_logo.svg under site/publish/. I'm not sure
why, but the one in notes/ was larger so I chose it.
The one under site/publish was a naive transformation of the original
artwork, which itself used design elements that extended
On 03/23/2018 02:04 AM, Daniel Shahaf wrote:
> Julian Foad wrote on Thu, 22 Mar 2018 22:24 +:
>> This question keeps coming up and I feel we should provide an accurate
>> answer, even if the procedure is not "supported".
>>
>> Any corrections to my current best effort, below?
>>
> As a first s
On 02/12/2018 04:04 PM, Karl Fogel wrote:
> Hi all. I think one of the import error messages in
> tools/hook-scripts/mailer/mailer.py is misleading (I discovered this while
> debugging the problem that Troy Curtis Jr. solved in r1823802). Any
> objections if I install this patch?
>
> [[[
> Giv
On 01/25/2018 07:16 PM, Johan Corveleyn wrote:
> Remaining problems:
> * Mapping users works, but only if there is a corresponding account on
> cwiki.a.o. Out of the 24 users that edited pages on our Moin wiki, 17
> don't have a confluence account (3 of which have only made a single
> edit to add t
On 09/14/2017 12:01 AM, Branko Čibej wrote:
> As you may have noticed, I started implementing support for multiple WC
> formats on the better-pristines branch, as a prelude to adding support
> for compressed pristines without forcing users to upgrade all their
> working copies.
Sweet!
> The other
ome book-material.
> More below ... ]
>
> On Thu, Jul 13, 2017 at 6:34 PM, C. Michael Pilato
> wrote:
> > On Thu, Jul 13, 2017 at 11:21 AM, Daniel Shahaf
> > wrote:
> >>
> >> [moving from users@ ]
> >>
> >> Daniel Shahaf wrote on Fri, 30 Ju
With respect to the author and the work he's done, I'm not really
interested in us maintaining yet *another* collection of the same
information already covered -- in some cases multiple times, when you
factor in the reference sections -- by the book. At best this cheatsheet
would be an appendix.
Yes, please do.
On 03/06/2017 10:15 AM, Doug Robinson wrote:
> Folks:
>
> I realize that the SHA1-collision issues are consuming most of the
> duty cycles at this point. Before I forget about this one - should I
> file a bug?
>
> Cheers!
>
> Doug
>
> On Thu, Mar 2, 2017 at 8:19 AM, Doug Robinson
On 01/24/2017 12:01 PM, Daniel Shahaf wrote:
> The bug is about 1.9 using a different order to 1.8. If we make
> svnadmin use the 1.8 unconditionally, then 1.9 will use a different
> order to 1.10, which essentially recreates the bug for other users.
>
> That is: the option serves to allow admins
On 08/11/2016 08:27 AM, Mark Phippard wrote:
> On Thu, Aug 11, 2016 at 8:22 AM, Ivan Zhakov <mailto:i...@visualsvn.com>> wrote:
>
> On 11 August 2016 at 15:17, C. Michael Pilato <mailto:cmpil...@collab.net>> wrote:
> > On 08/10/2016 08:44 AM, Ivan Zh
On 08/10/2016 08:44 AM, Ivan Zhakov wrote:
> Serf doesn't support Windows 2000 (due direct usage of SSPI).
>
> Given all above I propose to officially drop Windows 2000 support in
> Subversion and cleanup some Windows 2000 compatibility code.
Does this mean I need to upgrade my only Windows machin
Migration off of Tigris.org and onto ASF Jira seems the smartest option for
this project. +1
On Tue, Sep 15, 2015 at 5:59 AM, Bert Huijben wrote:
> Hi All,
>
>
>
> Here at the hackathon in Berlin we are discussing issue trackers, and more
> particular how we should eventually mo
Simply pop a mail off to dev-unsubscr...@subversion.apache.org, Katherine.
On Thu, Sep 10, 2015 at 3:07 PM, Katherine Sheehan
wrote:
> I'd like to unsubscribe to this mailing list please.
>
> Kind regards,
> Katherine
>
_description’ which uses ‘
> svn_wc__external_description_format_1’ and ‘
> svn_wc__external_description_format_2’ to handle the different formats.
>
>
>
> (In the pre 1.5 format the ‘-r’ is interpreted as a peg revision)
>
>
>
> Bert
>
>
>
> *From:* C
I was reading up on the new 'svn cp --pin-externals' feature in the 1.9
release notes. Great addition, by the way, and one that I hope to use
myself with ViewVC's release tags.
One question came to mind, though. The use of the feature appears to
result in pegged externals definitions (as in, @-b
On 05/14/2015 08:12 AM, Branko Čibej wrote:
> On 13.05.2015 15:24, C. Michael Pilato wrote:
>> I lean towards thinking that falls outside the scope of acceptable
>> changes in behavior in the 1.x line *unless* you can find a way to,
>> via configuration, allow administrators
On 05/13/2015 10:35 AM, Branko Čibej wrote:
On 13 May 2015 at 15:24, C. Michael Pilato
wrote:
Well, the use-case being broken here is kinda the obvious one: I
shouldn't have permission to create/delete some path /foo/bar (it's a
system-critical file that shouldn't go away
On 05/13/2015 02:21 AM, Stefan Fuhrmann wrote:
> Hi devs,
>
> At WANdisco, people have been playing with the new
> wildcard support for authz (see authz-performance branch)
> and ran into an interesting problem.
[Details snipped. Welcome to 2004, where CollabNet ran into the same
issues with the
le
resource differently than the somewhat unavoidable implicit attempts.
As for log levels, is there any reason to log the implicit read attempts
at a level higher than "debug"? I have no opinion about the log level
for the explicit ones.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
ry.
Alas, I haven't the time to devote any real attention to your patch or
subsequent iterations thereof. But I thought I'd at least respond with
a bit of encouragement.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
On 12/01/2014 12:04 PM, Alexey Neyman wrote:
>
> On 12/01/2014 06:17 AM, C. Michael Pilato wrote:
>> Just a quick question, as my bindings knowledge has grown somewhat
>> stale: why do some of the wrapper functions use a format string with
>> the tuple notation (e.g., &q
On Mon, Dec 1, 2014 at 2:24 AM, Alexey Neyman wrote:
> Hi all,
>
> Please review/comment.
>
Just a quick question, as my bindings knowledge has grown somewhat stale:
why do some of the wrapper functions use a format string with the tuple
notation (e.g., "(O)") and others not (e.g., "Oss#O&")?
I
On 10/01/2014 10:16 AM, Philip Martin wrote:
> Philip Martin writes:
>
>> "C. Michael Pilato" writes:
>>
>>> The log message for r2419 mentions "files" larger than 4Gb, and leads me
>>> to believe that this problem only affects GETs. But
On 10/01/2014 06:48 AM, Philip Martin wrote:
> Andreas Stieger writes:
>
>> I
>> will once again point to the serf issues below and httpd/network config.
>> https://code.google.com/p/serf/issues/detail?id=152
>> https://code.google.com/p/serf/source/detail?r=2419
> Andreas identified a bug in serf
to actually review it. I don't think there is any
> point in rushing a decision at this stage of 1.9 "slippage".
>
> -- Stefan^2.
I'm late to the party, but this all sounds great.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
#x27;s behavior without a driving
use-case beyond mere developer OCD seems like a waste of time of
energy. That said, it's neither my time nor energy at risk, so weigh my
input accordingly.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
, which is
trying its darnedest to act like a repos-layer dump/load driver but sits
on the other end of the higher RA layer?
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
ng that we knew what
information did and didn't matter to an administrator. This is why
svn_fs_props_changed() and svn_fs_contents_changed() never bothered to
compare the respective prop/text content, but merely noticed that the
DAG had or hadn't been adjusted.
--
C. Michael Pilato
C
On 09/18/2014 08:26 AM, Ivan Zhakov wrote:
> On 11 September 2014 18:03, C. Michael Pilato wrote:
> Mike,
>
>> Ivan: As a reviewer of the code in question, there's really no way
>> you could have established (for yourself) a legitimate objection
>> about the "
On 09/10/2014 05:37 PM, Branko Čibej wrote:
>
>
> > I have technical objections related to the general quality of the
> > new code. The best way to find out more is to review this code by
> > yourself!
>
> No. It's your veto and therefore the burden of evidence is on you.
> "General quality of code
On 09/10/2014 01:06 PM, Stefan Sperling wrote:
> I've been working on the log-message-templates branch recently.
> This branch was started by cmpilato a long time ago but for some
> reason sat around untouched ever since. It's now been overhauled
> by me with much help from Bert.
Just for a bit of
"transaction props" and "revision props" once we get outside our API
space and into user command space. Our users understand "revision
props" as properties on revisions, and transactions as revisions-to-be
... the rest is fairly trivial inference.
(And yes, 'svnlook' should be kept read-only.)
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
On 09/05/2014 08:03 AM, s...@apache.org wrote:
> Author: stsp
> Date: Fri Sep 5 12:03:35 2014
> New Revision: 1622687
>
> URL: http://svn.apache.org/r1622687
> Log:
> On the log-message-templates branch, change the contents of the
> log message template hash table passed to API consumers.
FWIW, I
On 08/26/2014 09:02 AM, Stefan Fuhrmann wrote:
> Personally, I'd be fine with renaming it. Others think
> we shouldn't do it because of "released". Realistically,
> we will break hardly anybody's setup by renaming it.
+1.
> Note that we
> never include such headers in current Subversion c
On 08/19/2014 09:27 AM, Stefan Fuhrmann wrote:
> On Tue, Aug 19, 2014 at 3:19 PM, C. Michael Pilato <mailto:cmpil...@collab.net>> wrote:
>
> On 08/19/2014 09:12 AM, stef...@apache.org
> <mailto:stef...@apache.org> wrote:
> > Author: stefan2
>
On 08/19/2014 09:12 AM, stef...@apache.org wrote:
> Author: stefan2
> Date: Tue Aug 19 13:12:48 2014
> New Revision: 1618860
>
> URL: http://svn.apache.org/r1618860
> Log:
> Move svn-bench from ./tools into ./subversion.
>
> * tools/client-side/svn-bench: Move from here to ...
> * subversion/svn-
On 07/29/2014 06:46 AM, Branko Čibej wrote:
> If we want to
> support wildcards, we /have/ to invent a different syntax for wildcard
> rules. My working proposal is to add a literal '*' before the leading
> slash in the path:
>
> [*/fspath-pattern]
> [repos:*/fspath-pattern]
>
> because n
On 07/07/2014 11:23 AM, Branko Čibej wrote:
> On 07.07.2014 17:07, C. Michael Pilato wrote:
>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>> My technical opinion that FSFS7/log addressing is slower by design,
>>> because it's doing more (read index, then read da
x27;m coming into this kinda late and after two weeks of vacation, so
please forgive me if I misunderstand the above, but is it true that
FSFS7 requires some kind of non-trivial caching just to match FSFS6's
performance?
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
tput that surely *countless* scripts have already been written to parse.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
e to me. In fact it sounds like an oversight that
> we didn't offer this originally.
IIRC, this was an intentional omission, as we knew that lock handling
would be terribly inefficient and that directory locks weren't supported.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
On 04/07/2014 11:10 AM, Branko Čibej wrote:
> On 07.04.2014 09:06, C. Michael Pilato wrote:
>> On 04/07/2014 10:58 AM, Ben Reser wrote:
>>> Let's adopt Johan's suggestion from the other thread.
>>>
>>> Specifically, for alpha/beta releases (no change
On 04/07/2014 10:58 AM, Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform (Windows/Unix)
> and
> at least 3 votes total.
Quick clar
t is the DB_REGISTER subsystem which
enforces that. I assume that what's happening is that your process
opens the original repository, copies the repository (which carries with
it the db.register file), and then upon trying to open the copied
repository runs into problems because BDB sees the
On 03/19/2014 11:12 AM, Bert Huijben wrote:
> Just to name a few: to set our binary properties, which we documented to just
> allow '*'
>
> svn:needs-lock
> svn:executable
This is a kinda soft one, since we automatically normalize the values of
these properties:
$ svn pset svn:executable '' io
ms was a major design goal from the
project's beginning.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
he deeznits.
Others dislike the inconsistency, and prefer instead:
* build/ac-macros/serf.m4:
(): Update the description.
(some_func): Twiddle the deeznits.
Once you establish a habit of the latter, it sorta follows that when you
have only top-level changes, you stick with your established pa
On 02/24/2014 01:56 PM, Philip Martin wrote:
> Thomas Åkesson writes:
>
>> Svn does not allow locking non-existent paths. It is blocked both in
>> libsvn_fs_base/libsvn_fs_fs as well as in mod_dav_svn. In the same
>> areas of the code in fs comments say:
>> "While our locking implementation easily
On 02/05/2014 05:45 AM, Julian Foad wrote:
> C. Michael Pilato wrote:
>
>> Mostly looking
>> for general feedback on the idea of the "sounds useful if it works" or
>> "you *really* don't want to go there" variety, but deeper review is of
&
Didn't want to commit this directly just yet, given my somewhat
disconnected attention level in the project as of late. Mostly looking
for general feedback on the idea of the "sounds useful if it works" or
"you *really* don't want to go there" variety, but deeper review is of
course welcome, too.
On 01/10/2014 02:00 PM, Ben Reser wrote:
> Wish that cleaning up pristines hadn't been overloaded into cleanup. Ran into
> a situation where I crashed the client today. So I needed to run cleanup, but
> I hadn't run cleanup in a very long time so of course it took a while since it
> also went thr
On 12/17/2013 10:06 AM, C. Michael Pilato wrote:
> Just piping in on this one point. POST is perfectly acceptable here,
> and is not in conflict with the DAV spec in the least. Just because we
> add a new route for locking/unlocked multiple paths (via POST) doesn't
> mean we&#
On 12/17/2013 09:35 AM, Branko Čibej wrote:
> I can't see us using POST instead of LOCK. AFAIU that's in conflict with
> the DAV spec; we already know that we could have writen a much more
> efficient custom HTTP protocol, and decided against it for good reasons.
> Pipelining LOCK requests sounds l
On 12/03/2013 04:08 AM, Evgeny Kotkov wrote:
> Hi,
>
> I've noticed that the 'recover_get_largest_revision' routine currently
> contains
> duplicate svn_pool_clear(ITERPOOL) calls. This change was introduced in
> r1546842 [1] and I've attached a patch to fix this.
Patch applied:
Sending
On 12/02/2013 04:32 AM, Philip Martin wrote:
> Daniel Shahaf writes:
>
>> Stefan Fuhrmann wrote on Thu, Nov 28, 2013 at 08:02:49 +0100:
>>> On Wed, Nov 27, 2013 at 11:34 PM, Philip Martin
>>> wrote:
>>>
>>> I'm a bit relucant to use them because I'm not altogether happy with the
way they are
On 11/26/2013 06:53 AM, Philip Martin wrote:
> Suppose svn_fs_commit_txn fails to complete, either due to a transient
> error like disk full or file permissions, or because the process is
> killed. Further suppose that the transaction remains on disk. Is it
> valid to call svn_fs_commit_txn again
On 11/22/2013 10:26 AM, Philip Martin wrote:
> We want to limit use of the system temp dir for various reasons:
>
> - the system dir may be a small filesystem with much less space than
> the working copy filesystem
>
> - if Subversion is interrupted files left in the system dir can't
>
On 11/11/2013 03:50 PM, Ryan Mulder wrote:
> When using svn 1.8.4 to update a working copy whose target url has a
> permanent redirect, the automatic relocate fails with error:
>svn: E155024: Invalid relocation destination: 'url' (does not point
> to target)
>
> This only happens when the work
On 11/07/2013 02:34 PM, Dirk wrote:
> It is utterly pointless to argue here.
[...]
> Unsubscribed before I get cancer or permanent brain damage from reading
> your passive-aggressive bullshit.
Uh... what just happened here?
I'm going to back up to the beginning of this thread, and see if we
can
On 10/29/2013 09:07 AM, br...@apache.org wrote:
> Author: brane
> Date: Tue Oct 29 13:07:49 2013
> New Revision: 1536700
>
> URL: http://svn.apache.org/r1536700
> Log:
> Begin converting C tests to use the same transient directory as the Python
> tests, so that both can be run off a RAM disk.
Gre
On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote:
> On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben Then most likely there is a difference between implementation and
> documentation
>
> svn ls -R path
>
> will use this function with deeper names.
>
> See list.c get_dir_contents()
gt;> [ Forwarding to list, with permission ]
>>
>> C. Michael Pilato wrote on Fri, Aug 09, 2013 at 10:06:25 -0400:
>>> On 08/09/2013 03:06 AM, Daniel Shahaf wrote:
>>>>> Ooh... option 3 is kind cool, and your use-case isn't particularly
>>>>> f
On 08/08/2013 09:40 AM, Daniel Shahaf wrote:
> On Thu, Aug 08, 2013 at 09:26:09AM -0400, C. Michael Pilato wrote:
>> This tells the options parser that there are no command-line options
>> which follow, which would keep self.__repospath from being treated as an
>> option in
On 08/08/2013 09:17 AM, Masaru Tsuchiyama wrote:
>> Also, it'd be good practice to pass "--" in front of self.__repospath,
>> but that
>> appears to be a preexisting problem in the code (i.e., not introduced
>> by your
>> patch).
>
> What is the purpose in passing "--"?
This tells the options par
On 07/22/2013 11:53 AM, phi...@apache.org wrote:
> Author: philip
> Date: Mon Jul 22 15:53:28 2013
> New Revision: 1505722
>
> URL: http://svn.apache.org/r1505722
> Log:
> * subversion/tests/cmdline/getopt_tests_data/svn--help_stdout:
> * subversion/tests/cmdline/getopt_tests_data/svn_help_stdout:
On 07/20/2013 02:42 AM, Masaru Tsuchiyama wrote:
Hi.
I implement 'youngest' sub command to svn, and attach a patch.
Masaru,
Thanks for the patch. I didn't do a full review of it, but it looks as
if you're taking the correct approach. I did quickly notice some things
that could be improve
On 07/19/2013 08:37 PM, Masaru Tsuchiyama wrote:
Hi.
I attach a patch to add sub command 'youngest' to svnrdump.
[[[
add sub command 'youngest' to svnrdump
* subversion/svnrdump/svnrdump.c
(svnrdump__cmd_table): Add an entry for youngest sub command.
(main): Print youngest
On 07/09/2013 10:33 AM, Ben Reser wrote:
So we had a conversation on IRC this morning about solutions.
This is what several of us seemed to agree was a reasonable compromise:
Have a tri-state option called http-chunked-requests. It would have
three states:
auto = Run the extra OPTIONS request
On 07/09/2013 10:47 AM, Ben Reser wrote:
On Tue, Jul 9, 2013 at 10:12 AM, Ivan Zhakov wrote:
I think it worth to release 1.8.1 without chunked requests proxy fixes:
1. We have 75 revisions merged to 1.8.x since 1.8.0. Some of them
critical. (see attached file)
2. Discussion about chunked reques
On 07/01/2013 05:37 PM, Daniel Shahaf wrote:
> How about adding 'svn cleanup --rm-I' as a short option for 'svn cleanup
> --remove-ignored'?
File an ENHANCEMENT issue with a note to evaluate later whether there is
sufficient user demand for the option?
--
C.
On 07/01/2013 02:16 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Mon, Jul 01, 2013 at 14:13:50 -0400:
>> I saw the "user-agent" change go through. What about "compat-version"? Did
>> you intentionally omit that one?
>
> No; svn:txn-client-
On 07/01/2013 02:01 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Mon, Jul 01, 2013 at 13:23:59 -0400:
>> On 07/01/2013 11:54 AM, Daniel Shahaf wrote:
>>> SVN_RA_CAPABILITY_EPHEMERAL_TXNPROPS seems to be queried only by the
>>> libsvn_ra_serf and libsvn_ra_svn
1 - 100 of 1784 matches
Mail list logo
