On Thu, 13 Sep 2018, 22:23 Branko Čibej, wrote:
> On 13.09.2018 13:08, Branko Čibej wrote:
> > On 13.09.2018 13:01, Stefan Sperling wrote:
> >> It should not be too hard to automate the process. The release.py
> >> script already has some commands which spit out HTML snippets for
> >> the news pa
On 13.09.2018 13:08, Branko Čibej wrote:
> On 13.09.2018 13:01, Stefan Sperling wrote:
>> It should not be too hard to automate the process. The release.py
>> script already has some commands which spit out HTML snippets for
>> the news pages so it might as well be parsing CHANGES and produce
>> HT
Branko Čibej wrote:
> Stefan Sperling wrote:
> > How about we provide a linkified version of CHANGES in our
> > release notes HTML pages? [...] based on only the respective
> > release's section of the CHANGES file [...]. For instance, the page
> > http://subversion.apache.org/docs/release-notes/1.
gt; > https://svn.apache.org/r [...]
>
> That's a good start (let's do it), [...]
I added a comment to the CHANGES file, based on that suggestion, in
http://svn.apache.org/r1840799 .
--
- Julian
On 13.09.2018 13:01, Stefan Sperling wrote:
> On Thu, Sep 13, 2018 at 11:50:57AM +0100, Julian Foad wrote:
>> Stefan Sperling wrote:
>>> I don't think many people follow these references when reading CHANGES.
>> [...]
>>> I believe a short note at the top of the file which explains how to
>>> resol
On Thu, Sep 13, 2018 at 11:50:57AM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > I don't think many people follow these references when reading CHANGES.
> [...]
> > I believe a short note at the top of the file which explains how to
> > resolve these references would be sufficient. Somethi
Stefan Sperling wrote:
> I don't think many people follow these references when reading CHANGES.
[...]
> I believe a short note at the top of the file which explains how to
> resolve these references would be sufficient. Something like this maybe:
>
> To view a revision listed in change log entr
On Thu, Sep 13, 2018 at 10:01:25AM +0100, Julian Foad wrote:
> It seems to me rather poor that readers of our CHANGES file have to manually
> follow references to revision numbers and issue numbers. Examples:
> [[[
> - Server-side bugfixes:
> * svnadmin dump shouldn't canonicalize svn:date (
On Thu, Sep 13, 2018 at 12:00:39PM +0200, Branko Čibej wrote:
> Given all the debate we've had about how to edit and merge the CHANGES
> file on trunk and release branches ... how about only having the change
> log in the wiki, with CHANGES containing only a pointer to the wiki page?
My impression
y, updated at least at every release and
>> preferably more often.
>>
> I suggest to create a wiki variant (with hyperlinks) on our Confluence
> wiki, rather than just a HTML-ized version. That should be doable to
> automate, to go over the plain text version and replace #4767 i
on our Confluence
wiki, rather than just a HTML-ized version. That should be doable to
automate, to go over the plain text version and replace #4767 into
[#4767|https://.../SVN-4767] etc.
(sorry, I'm not volunteering right now, it's just a suggestion -- I
might find some time in a couple of weeks, but not immediately ... so
if anyone else feels inclined ...)
--
Johan
Markdown seems ubiquitous nowadays. In its raw form it is human readable,
as well as being machine-parsable into HTML / PDF, etc.
Git's README is markdown (https://github.com/git/git/blob/master/README.md)
but the releases notes are still plain text (
https://raw.githubusercontent.com/git/git/mas
It seems to me rather poor that readers of our CHANGES file have to manually
follow references to revision numbers and issue numbers. Examples:
[[[
- Server-side bugfixes:
* svnadmin dump shouldn't canonicalize svn:date (issue #4767)
* 'svnadmin verify --keep-going --quiet' shows an erro
One can use WebDAV's PROPFIND to list the contents of a directory in
Subversion. You won't be told the Subversion revision for any of the
directory results however, but you will for the file items in the result
set.
You have to do an OPTIONS and a PROPFIND call for each directory one at a
time to
Filed - https://issues.apache.org/jira/browse/SVN-4710
On Mon, Dec 11, 2017 at 10:21 AM, Paul Hammant wrote:
> Jira feature request needed to capture anything from this thread? Maybe
> not, if plans were already in action anyway...
I'd say yes, please put something in JIRA, because (it seems to me)
those plans are quite "soft" at the moment. It migh
Jira feature request needed to capture anything from this thread? Maybe
not, if plans were already in action anyway...
>
>
> Specifically, by "currently" I mean that this is the state on trunk. :)
> I don't believe anyone is working on adding explicit traversal
> permission on trunk in time for 1.10. It would require some rework of
> the way the authz info is used within the core libraries, it's not just
> a questi
On 10.12.2017 14:46, Paul Hammant wrote:
> > Currently it's implied in 'r' and 'rw' modes.
>
> Great news. Specifically by currently you mean in 1.9.7 right? And
> that further enhancements are Coming in 1.10.
>
> You also said you’ve a plan for further enhancements :)
Specifically, by "currentl
> Currently it's implied in 'r' and 'rw' modes.
Great news. Specifically by currently you mean in 1.9.7 right? And that
further enhancements are Coming in 1.10.
You also said you’ve a plan for further enhancements :)
On 10.12.2017 10:28, Paul Hammant wrote:
> Consider:
>
> [/]
> harry=rw
>
> [dataset:/A]
> sally=rw
>
> [dataset:/Z]
> sally=rw
>
>
> If I had directories B through Y, I am pretty sure Sally cannot see
> them let along change anything in them. Cool that's what I want.
>
> Wh
Consider:
[/]
harry=rw
[dataset:/A]
sally=rw
[dataset:/Z]
sally=rw
If I had directories B through Y, I am pretty sure Sally cannot see them
let along change anything in them. Cool that's what I want.
What I don't have though is the ability for Sally to checkout from root and
recieve A/* and B
On Thu, Sep 21, 2017 at 12:16 PM, Paul Hammant wrote:
>>
>>
>> 2. Previously I forked a medium-sized Monorepo on Github, and did the the
>> complete expand/contract work for it -
>> https://github.com/paul-hammant-fork/jooby-monorepo-experiment - in Python.
>>
>
> LOGIBALL's Tim Krüger has just wr
>
>
> I'm not sure if you agree or not, but I think the fine-grained globbing
> include/exclude capability as Perforce has it. is required.
>
>
> "Required" implies "working copy format change". That's always hard.
>
> "Optional" means "get some of the features sooner."
>
I'm a big advocate for "s
On 21.09.2017 12:08, Paul Hammant wrote:
>
> [...]
>
> if /foo does not exist at checkout time -- and if we'd want /* to mean
> "include anything new that appears in the repository", not "include
> everything else that's in the repository at the time of the checkout".
>
>
> I'm not
>
>
>
> 2. Previously I forked a medium-sized Monorepo on Github, and did the the
> complete expand/contract work for it - https://github.com/paul-hamm
> ant-fork/jooby-monorepo-experiment - in Python.
>
>
LOGIBALL's Tim Krüger has just written about a deployment of an
expanding/contracting monorep
>
> [...]
>
> if /foo does not exist at checkout time -- and if we'd want /* to mean
> "include anything new that appears in the repository", not "include
> everything else that's in the repository at the time of the checkout".
>
I'm not sure if you agree or not, but I think the fine-grained globb
On 20.09.2017 08:48, Branko Čibej wrote:
> On 19.09.2017 18:05, Branko Čibej wrote:
>> On 19.09.2017 13:24, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
On 19.09.2017 00:59, Paul Hammant wrote:
> I like the `svn co svn://vcs/trunk --view foo`. Well maybe if
On 19.09.2017 18:05, Branko Čibej wrote:
> On 19.09.2017 13:24, Daniel Shahaf wrote:
>> Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
>>> On 19.09.2017 00:59, Paul Hammant wrote:
I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
following `svn up` it would *remember
On 19.09.2017 13:24, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
>> On 19.09.2017 00:59, Paul Hammant wrote:
>>> I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
>>> following `svn up` it would *remember the current view*, it would be good.
>>
>> I d
Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
> On 19.09.2017 00:59, Paul Hammant wrote:
> > I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
> > following `svn up` it would *remember the current view*, it would be good.
>
>
> I don't think there's any need to remember the
> On 19.09.2017 00:59, Paul Hammant wrote:
> > I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
> > following `svn up` it would *remember the current view*, it would be
> good.
>
>
> I don't think there's any need to remember the "current view": a sparse
> working copy already mai
On 19.09.2017 00:59, Paul Hammant wrote:
> I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
> following `svn up` it would *remember the current view*, it would be good.
I don't think there's any need to remember the "current view": a sparse
working copy already maintains its top
I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
following `svn up` it would *remember the current view*, it would be good.
> I'm not sure about listing the "available views" in a default
> property, but okay, it's a possibility. I think it would be nice to be
> able to read it
On Wed, Sep 13, 2017 at 12:45 PM, Paul Hammant wrote:
>>
>>
>> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py
>>
>
> Excellent!
>
> I see you posted a StackOverflow answer on that too, Mark -
> https://stackoverflow.com/questions/7481860/create-folder-structure-
On 16.09.2017 20:06, Paul Hammant wrote:
>
>
> foo.py:
>
> import os
> def my_mocked_os_system(*args, **kwargs):
> print('a mockery')
> os.system = my_mocked_os_system
>
>
> bar.py:
>
> import os
> os.system("echo bar")
>
> import foo
> os.system("echo fo
>
>
> foo.py:
>
> import os
> def my_mocked_os_system(*args, **kwargs):
> print('a mockery')
> os.system = my_mocked_os_system
>
>
> bar.py:
>
> import os
> os.system("echo bar")
>
> import foo
> os.system("echo foo")
>
>
> Then:
>
> $ PYTHONPATH=. python bar.py
> bar
> a mockery
>
>
I've spent
On 14.09.2017 15:49, Paul Hammant wrote:
> Would I retain the previous value of os.system and set it back after
> any assertions (pass or fail) so that following tests would not affected?
> Or does it und itself naturally when Pytest recurses in the next test
> in its suite ?
It wouldn't undo itse
Would I retain the previous value of os.system and set it back after any
assertions (pass or fail) so that following tests would not affected?
Or does it und itself naturally when Pytest recurses in the next test in
its suite ?
As I hinted I couldn't find such an example online, with an emphatic '
On 14.09.2017 15:29, Paul Hammant wrote:
>
> Yes, that one's pretty nice, but as a rule we try not to burden our
> users with dependencies outside the standard library. The script uses
> os.system, what, twice? Hardly worth replacing.
>
> On the other hand, we have wrappers around s
>
> Yes, that one's pretty nice, but as a rule we try not to burden our
> users with dependencies outside the standard library. The script uses
> os.system, what, twice? Hardly worth replacing.
>
> On the other hand, we have wrappers around subprocess.Popen in
> subversion/tests/cmdline/svntest/mai
On 14.09.2017 15:04, Paul Hammant wrote:
> My aim was to minimally impact the prod source. The context object is
> a good idea.
>
> I've been using https://amoffat.github.io/sh/ and quite enjoying it
> for my other python/svn project.
Yes, that one's pretty nice, but as a rule we try not to burden
My aim was to minimally impact the prod source. The context object is a
good idea.
I've been using https://amoffat.github.io/sh/ and quite enjoying it for my
other python/svn project.
On 14.09.2017 14:50, Paul Hammant wrote:
> I ran pep8 over the sources and thought I'd remediated all the
> training spaces already. I'll finish the job.
>
> My alternative to the four globals is to pass the function pointers as
> parameters through one or two intermediates to the functions that
>
I ran pep8 over the sources and thought I'd remediated all the training
spaces already. I'll finish the job.
My alternative to the four globals is to pass the function pointers as
parameters through one or two intermediates to the functions that would use
them. Would that be acceptable? I can't
On 14.09.2017 12:26, Paul Hammant wrote:
> Thanks.
>
> Here's what I expect to land - https://github.com/apache/subversion/pull/5
Why o why did you go to the trouble of adding the global variables in
svn-viewspec.py? They add exactly zero value and cause nothing but code
churn. -1 to that change
Thanks.
Here's what I expect to land - https://github.com/apache/subversion/pull/5
Ten tests - ten passing in less than 0.1s
I don't know if there is a clean workflow from Git commits back into
Subversion so, I'll make the same commit through the Svn HTTPS interface,
if code review comments are a
On 13.09.2017 19:47, Paul Hammant wrote:
> OK, so I am up at 93% coverage with a PyTest script. As an Apache
> Member I'm already CLA'd. I could start to write tests that break the
> script in ways that it should handle more gracefully, but I need
> assurance that I'm not wasting my time.
>
> I'm n
On 13.09.2017 12:40, Paul Hammant wrote:
>
> > This is an old idea. If you want to implement it, a file is
> not the
> > right place for the view definition; a property on a directory
> > might be.
> >
> >
> > A Svn property that sets for the user and workspa
OK, so I am up at 93% coverage with a PyTest script. As an Apache Member
I'm already CLA'd. I could start to write tests that break the script in
ways that it should handle more gracefully, but I need assurance that I'm
not wasting my time.
I'm not expecting committership (especially since my last
T'was line endings and redundant spaces, fixed with a strip(), but as I
say, Java's asserts are better to noobs.
Here's the test:
https://gist.github.com/paul-hammant/058161485a227299e5d7c34cc6a33264
I had to refactor the actual script too. A tiny backwards-compatible bit.
-ph
I have a test for the inlined example. Well it would pass, but PyTest's
assert function is about 10x inferior to JUnit's or Hamcrest's
assertEquals() and isn't telling me where I've futzed up a CR somewhere.
This even *with* optional args (that should be mandatory -s and -vv). Gotta
go to work now
On Wed, Sep 13, 2017 at 06:53:14AM -0400, Paul Hammant wrote:
> Oh tools/client-side/svn-viewspec.py doesn't have any tests :-(
>
> The good news is that it can be refactored to have test quite easily. I
> think I'll be able to donate some code.
I would also be happy to see further improvements t
Oh tools/client-side/svn-viewspec.py doesn't have any tests :-(
The good news is that it can be refactored to have test quite easily. I
think I'll be able to donate some code.
>
>
> http://svn.apache.org/repos/asf/subversion/trunk/tools/
> client-side/svn-viewspec.py
>
>
Excellent!
I see you posted a StackOverflow answer on that too, Mark -
https://stackoverflow.com/questions/7481860/create-folder-structure-based-on-file
I'm one of those people that's blind to a lib or
> > This is an old idea. If you want to implement it, a file is not the
> > right place for the view definition; a property on a directory
> > might be.
> >
> >
> > A Svn property that sets for the user and workspace only, and retains
> > no history, right? Meaning if the user had two
Have you seen:
http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py
> On Sep 12, 2017, at 10:22 PM, Paul Hammant wrote:
>
> Compared to Perforce's client-spec, Subversion's sparse checkouts are quite
> cumbersome:
>
> svn checkout http://svn.apache.org/repos/as
On 13.09.2017 09:25, Paul Hammant wrote:
>
> This is an old idea. If you want to implement it, a file is not the
> right place for the view definition; a property on a directory
> might be.
>
>
> A Svn property that sets for the user and workspace only, and retains
> no history, right?
>
> This is an old idea. If you want to implement it, a file is not the
> right place for the view definition; a property on a directory might be.
>
A Svn property that sets for the user and workspace only, and retains no
history, right? Meaning if the user had two checkouts of the same Svn URL,
On 13.09.2017 04:22, Paul Hammant wrote:
> Compared to Perforce's client-spec, Subversion's sparse checkouts are
> quite cumbersome:
>
> svn checkout http://svn.apache.org/repos/asf/subversion
> --depth=immediates
> cd subversion/trunk
> svn update --set-depth infinity
> cd ../t
Compared to Perforce's client-spec, Subversion's sparse checkouts are quite
cumbersome:
svn checkout http://svn.apache.org/repos/asf/subversion --depth=immediates
cd subversion/trunk
svn update --set-depth infinity
cd ../tags
svn update --set-depth immediates
cd 1.7.7
svn update --set-depth infini
Daniel Shahaf wrote:
>Lorenz wrote on Thu, Feb 23, 2017 at 07:33:54 +:
>[...]
>>
>> But back to original topic: I could live with using '^./' as the
>> general prefix for "current working copy folder relative addressing".
>>
>> so my 4 examples above would change to:
>>
>> ^./subpath subpa
Lorenz wrote on Thu, Feb 23, 2017 at 07:33:54 +:
> Daniel Shahaf wrote:
> >Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +:
> >> Stefan Sperling wrote:
> >> >From 'svn help ps':
> >> > The URL may be a full URL or a relative URL starting with one of:
> >> >../ to the parent di
Branko ?ibej wrote:
>On 22.02.2017 17:42, Daniel Shahaf wrote:
>> Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +:
>>> Stefan Sperling wrote:
>>> >From 'svn help ps':
The URL may be a full URL or a relative URL starting with one of:
../ to the parent directory of the ext
bpath subpath of the current working copy folder
> >> ^../ parent
> >> ^../path sibling
> >> ^../../grand parent
> > If the first of these four were changed to require a ./ path component,
>
> ... then it would not be backward c
On 22.02.2017 17:42, Daniel Shahaf wrote:
> Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +:
>> Stefan Sperling wrote:
>> >From 'svn help ps':
>>> The URL may be a full URL or a relative URL starting with one of:
>>>../ to the parent directory of the extracted external
>>>
Daniel Shahaf wrote:
>Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +:
>> Stefan Sperling wrote:
>> >From 'svn help ps':
>> > The URL may be a full URL or a relative URL starting with one of:
>> >../ to the parent directory of the extracted external
>> >^/ to the reposit
Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +:
> Stefan Sperling wrote:
> >From 'svn help ps':
> > The URL may be a full URL or a relative URL starting with one of:
> >../ to the parent directory of the extracted external
> >^/ to the repository root
> >/to
Stefan Sperling wrote:
>On Wed, Feb 22, 2017 at 03:12:55PM +0100, Harald Kirsch wrote:
>> Am 21.02.2017 um 15:40 schrieb Lorenz:
>> > And why not use "^^/" to denote working copy root relative?
>>
>> Would work for me. But intuitively ^^/ seems to refer even higher up in the
>> directory hierarch
On Wed, Feb 22, 2017 at 03:12:55PM +0100, Harald Kirsch wrote:
> Am 21.02.2017 um 15:40 schrieb Lorenz:
> > And why not use "^^/" to denote working copy root relative?
> >
>
> Would work for me. But intuitively ^^/ seems to refer even higher up in the
> directory hierarchy than ^/, but its not, s
Am 21.02.2017 um 15:40 schrieb Lorenz:
Harald Kirsch wrote:
[about working copy relative URLs]
This a purely client side path to URL transformation.
So what is needed as a means to tell the client to use the URL
associated with the given path.
there is already the "^/" notation to tell the
Harald Kirsch wrote:
>[about working copy relative URLs]
This a purely client side path to URL transformation.
So what is needed as a means to tell the client to use the URL
associated with the given path.
there is already the "^/" notation to tell the command line client
that you what to start a
Hi all,
as suggested by Johan, I dare to drop a feature suggestion onto this
mailing list.
In a multi project repository, ^/trunk and ^/branches do not usually
point to the trunk and branches of a project. Rather something like
^/somedir/someproject/branches
is needed.
Given a working
David Radcliffe wrote:
> Julian,
>
> Thanks for considering my suggestion, and your detailed reply.
>
> Yes, 'sparse branching' does nicely describe the effect I am trying to
> achieve. I do appreciate that any form of 'variants' is going to cause a
>
Julian,
Thanks for considering my suggestion, and your detailed reply.
Yes, 'sparse branching' does nicely describe the effect I am trying to achieve.
I do appreciate that any form of 'variants' is going to cause a management
overhead.
The specific problems I'm t
Hi David.
Thank you for writing in with your suggestion. It took me a while to really
grasp the essence of it, which I think is
Sparse branching at the granularity of text hunks
where by "branching" I just mean tracking parallel streams of development in
some way.
Thin
becomes unwieldy
2. This creates a maintenance nightmare when applying patches or
updates
3. This works, but implementation (e.g. Visual Studio) leaves a lot to
be desired.
This suggestion proposes a fourth method: Conditional Check-out.
This works (as far as the complier is concerned
On 03/28/2012 08:38 AM, C. Michael Pilato wrote:
> On 03/28/2012 03:55 AM, Josef RIESENEDER wrote:
>>
>> Hello,
>> I have an suggestion for checking the user access. It would be nice to use a
>> regex in the path instead of the full path.
>>
>> Instead of thi
On 03/28/2012 03:55 AM, Josef RIESENEDER wrote:
>
> Hello,
> I have an suggestion for checking the user access. It would be nice to use a
> regex in the path instead of the full path.
>
> Instead of this:
> [/currTree/trunk/config]
> @user = rw
> [/currTree/branches/b
On Wed, Mar 28, 2012 at 2:55 AM, Josef RIESENEDER
wrote:
>
> Hello,
> I have an suggestion for checking the user access. It would be nice to use a
> regex in the path instead of the full path.
>
> Instead of this:
> [/currTree/trunk/config]
> @user = rw
> [/currT
Josef RIESENEDER writes:
> I have an suggestion for checking the user access. It would be nice to use
> a regex in the path instead of the full path.
>
> Instead of this:
> [/currTree/trunk/config]
> @user = rw
> [/currTree/branches/branch1/config]
> @user = rw
>
>
Hello,
I have an suggestion for checking the user access. It would be nice to use
a regex in the path instead of the full path.
Instead of this:
[/currTree/trunk/config]
@user = rw
[/currTree/branches/branch1/config]
@user = rw
It should be possible to use simply a regex:
[/currTree/.*/config
Ruhe Julian wrote on Mon, Mar 05, 2012 at 13:59:10 +:
> Thank you for your answer. I missed that svn_ra_get_deleted_rev() is
> part of the server’s API. Thought it was client API.
All svn_ra_* APIs are ones that the server presents to clients. ("RA"
stands for "repository access".)
Many of t
object (identified by
path@peg).
Greetings,
Julian
Von: C. Michael Pilato [mailto:cmpil...@collab.net]
Gesendet: Montag, 5. März 2012 14:09
An: Ruhe Julian
Cc: dev@subversion.apache.org
Betreff: Re: AW: Suggestion for: "Improve svn log with 'forward' revision
range" (Issue 3830)
release. That’s why
> I am interested in this topic.
>
>
>
> Greetings,
>
> Julian
>
>
>
>
>
>
>
> *Von:*C. Michael Pilato [mailto:cmpil...@collab.net]
> *Gesendet:* Freitag, 2. März 2012 16:00
> *An:* Ruhe Julian
> *Cc:* dev@subversion.apache
[mailto:cmpil...@collab.net]
Gesendet: Freitag, 2. März 2012 16:00
An: Ruhe Julian
Cc: dev@subversion.apache.org
Betreff: Re: Suggestion for: "Improve svn log with 'forward' revision range"
(Issue 3830)
I'm pretty sure "valid" in this sense means "passes the
SVN)_IS_
to
> get an useful answaer an not an exception.
>
>
>
> *Von:*C. Michael Pilato [mailto:cmpil...@collab.net]
> *Gesendet:* Freitag, 2. März 2012 15:32
> *An:* Ruhe Julian
> *Cc:* dev@subversion.apache.org
> *Betreff:* Re: Suggestion for: "Improve svn log with 'fo
end_revision to get an useful answaer an not an exception.
Von: C. Michael Pilato [mailto:cmpil...@collab.net]
Gesendet: Freitag, 2. März 2012 15:32
An: Ruhe Julian
Cc: dev@subversion.apache.org
Betreff: Re: Suggestion for: "Improve svn log with 'forward' revision range"
(Issue 3830
ls in respect of a suggestion I
> wanted to make for issue 3830
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3830
>
>
>
> It took me some time to understand that it is _/not/_ possible for the svn
> client to display the future of an object in some revision when
Hi,
Stefan Sperling asked me to post some details in respect of a suggestion I
wanted to make for issue 3830
http://subversion.tigris.org/issues/show_bug.cgi?id=3830
It took me some time to understand that it is _not_ possible for the svn client
to display the future of an object in some
: Peter Samuelson
>>> Cc: dev@subversion.apache.org
>>> Subject: Re: Minor patch suggestion:
>>>
>>> On 14 October 2011 18:25, Peter Samuelson wrote:
>>> >
>>> > [Mat Booth]
>>> >> --- subversion/libsvn_subr/cmdline.c (revi
On Mon, Oct 17, 2011 at 4:42 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Mat Booth [mailto:mat.bo...@wandisco.com]
>> Sent: maandag 17 oktober 2011 12:26
>> To: Peter Samuelson
>> Cc: dev@subversion.apache.org
>> Subject: Re: Minor
> -Original Message-
> From: Mat Booth [mailto:mat.bo...@wandisco.com]
> Sent: maandag 17 oktober 2011 12:26
> To: Peter Samuelson
> Cc: dev@subversion.apache.org
> Subject: Re: Minor patch suggestion:
>
> On 14 October 2011 18:25, Peter Samuelson w
On 14 October 2011 18:25, Peter Samuelson wrote:
>
> [Mat Booth]
>> --- subversion/libsvn_subr/cmdline.c (revision 1183368)
>> +++ subversion/libsvn_subr/cmdline.c (working copy)
>> @@ -32,8 +32,10 @@
>> #include
>> #include
>> #else
>> +#if _MSC_VER >= 1400
>> #include
>> #endif
>> +#en
[Mat Booth]
> --- subversion/libsvn_subr/cmdline.c (revision 1183368)
> +++ subversion/libsvn_subr/cmdline.c (working copy)
> @@ -32,8 +32,10 @@
> #include
> #include
> #else
> +#if _MSC_VER >= 1400
> #include
> #endif
> +#endif
Looks reasonable ... but then when I scrolled down the fil
Hi all,
I'd like to suggest a trivial patch to make it easier to build
Subversion 1.7 on Windows with older Microsoft and non-Microsoft
compilers.
Please see attached.
It just applies the same pre-processor condition to the inclusion of
crtdbg.h as you already have for the use of functions from
Hi David,
First, I think usage questions are better directed to
us...@subversion.apache.org list.
As to your question: the asterisk (*) you pass as an argument is, most
probably, not even seen by Subversion. Instead, it is expanded to the actual
list of files and directories by your shell. Whi
Subversion Dev team:
Thanks for all your hard work. I just began using subversion and it is
great.
Among other things, it is fast.
One complaint.
As a new user it was my expectation that 'svn add *' called from within the
root
of my version-controlled root directory would result in *all* change
> -Original Message-
> From: Branko Čibej [mailto:br...@xbc.nu]
> Sent: Thursday, July 29, 2010 10:05 AM
> To: dev@subversion.apache.org
> Subject: Re: Suggestion: Transparent Branching
>
> On 07.07.2010 18:29, Greg Hudson wrote:
> > On Wed, 2010-07-07 at 11:4
On 07.07.2010 18:29, Greg Hudson wrote:
> On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote:
>
>> So therefor, what we would like to see is to be able to have a transparent
>> branch: One which fetches updates from both branch and trunk, without having
>> them listed as changes or triggering
1 - 100 of 104 matches
Mail list logo
