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.
Julian Foad wrote:
> Stefan Sperling wrote:
> > 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 entries below, visit:
> > https://svn.apache.org/rXXX
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
On 13.09.2018 11:18, Johan Corveleyn wrote:
> On Thu, Sep 13, 2018 at 11:01 AM 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:
>> * svna
On Thu, Sep 13, 2018 at 11:01 AM 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 (issue
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
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
> management overhead.
A few more thoughts,
feel about this?
I haven't had a chance to try implementing anything. If I get time, I might try
the post-check-out script idea...
Thanks again, Dave Radcliffe
-Original Message-
From: Julian Foad [mailto:julianf...@btopenworld.com]
Sent: 09 July 2014 12:06
To: David Radcliffe
Cc: de
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.
Thinking about configura
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 this:
>> [/currTree/trunk/config]
>> @user
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/branch1/config]
> @user = rw
>
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
> [/currTree/branches/branch1/config]
> @use
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
>
> It should be possible to use s
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
Doing this inside our client code would be significantly easier, because
that code has access to the svn_ra_get_deleted_rev() API.
/**
* Given @a path at revision @a peg_revision, set @a *revision_deleted to the
* revision @a path was first deleted, within the inclusive revision range
* defined
> -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
> -Original Message-
> From: Marco Jansen [mailto:sart...@gmail.com]
> Sent: Wednesday, July 07, 2010 4:44 PM
> To: dev@subversion.apache.org
> Subject: Suggestion: Transparent Branching
>
> Greetings,
>
> The issue we have is that we use trunk as a stable version, but with
ongoing
> main
Hello Marco,
On Wednesday 07 July 2010, 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 commits. In
> essence it's reading from two
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 commits. In essence it's reading from
> two branc
27 matches
Mail list logo
