One of the limitations I am hitting on shelving is inconsistent API for sending
modifications from and to a WC.
The APIs need to support complete WC changes including multi-layered copy
operations.
For getting changes out of the WC, what better API than the one we use to
commit? That necessari
On Sat, Jul 14, 2018 at 10:55 PM, Julian Foad wrote:
> The 1.10.2 release artifacts are now available for testing/signing.
>
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Note that this is code-wise identical to 1.10.1; on
Johan Corveleyn wrote on Mon, 16 Jul 2018 21:46 +0200:
> (why would CHANGES in a 1.9.x tarball need to contain changes of the
> 1.8 line?)
I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of
1.8.y with y>1, since the contents of those sections are repeated under
1.9.x sections, b
On Mon, Jul 16, 2018 at 6:57 PM, Daniel Shahaf wrote:
> Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
>> Actually the "sync merge" way isn't as automatic as I would like. The
>> merge always conflicts when there is a new or modified trunk CHANGES
>> entry for 1.10.x. Maybe --accept=mine-confl
On Sat, Jul 14, 2018 at 10:54 PM, Julian Foad wrote:
> The 1.9.9 release artifacts are now available for testing/signing.
>
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Note that this is code-wise identical to 1.9.8; only
Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
> Actually the "sync merge" way isn't as automatic as I would like. The
> merge always conflicts when there is a new or modified trunk CHANGES
> entry for 1.10.x. Maybe --accept=mine-conflict would completely solve
> that. Haven't tested that.
Julian Foad wrote:
> Stefan Sperling wrote:
> >I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
> >deleted any entries above the one for the release being prepared.
> >
> >This worked quite well for me and I never found it burdensome.
>
> That, or scripting that as Johan sugge
Dmitry Pavlenko wrote:
> When I apply Git format patch that adds a directory with properties, a file
> is
> added instead.
Thank you for testing and finding these issues, Dmitry!
> Here I provide a reproducing script and also add a file for comparison.
>
> I think the origin of the problem in
Hello!
When I apply Git format patch that adds a directory with properties, a file is
added instead.
Here I provide a reproducing script and also add a file for comparison.
I think the origin of the problem in the fact that SVN patch doesn't keep
"node kind". But a patch in "svn diff --git" for
Summary:
+1 to release (Unix)
Verified:
- Tarball contents and signatures
- check ((fsfs, bdb) × (local, svnserve, dav))
- check-all-javahl
- check-swig-py
- check-swig-rb
- check-swig-pl
Known issues:
- 'make check-swig-py' requires 'make install install-swig-py'.
Probab
Marcin also suggested we take a look at Mercurial's release schedule Wiki page
for any inspiration we can draw from it:
https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan
- Julian
Julian Foad wrote:
> > Committed to http://subversion-staging.apache.org/roadmap.html in
> > http://svn.apac
Julian Foad wrote:
> > Yes, +1 on this lighter proposal.
>
> Committed to http://subversion-staging.apache.org/roadmap.html in
> http://svn.apache.org/r1835861 [...]
>
> OK?
My thoughts:
* should say patch releases are not time-based but ad-hoc (Marcin K. just asked
about this on IRC)
* shou
On Mon, Jul 16, 2018 at 12:01 PM, Julian Foad wrote:
>>> Johan Corveleyn wrote:
It seems something went wrong with the "Post-release housekeeping"
commits on the 1.10.x branch, r1835806 (post 1.10.1) and r1835936
(post 1.10.2): they contain an empty diff for svn_version.h ... weird.
Thanks for the report. It would be great if you could file an issue and write a
test for this problem.
- Julian
Dmitry Pavlenko wrote on 2018-07-11:
> The following scenario fails for me: delete a file, create a symlink with the
> same name, run "svn diff". Instead of displaying the diff, SVN
>> Johan Corveleyn wrote:
>>> It seems something went wrong with the "Post-release housekeeping"
>>> commits on the 1.10.x branch, r1835806 (post 1.10.1) and r1835936
>>> (post 1.10.2): they contain an empty diff for svn_version.h ... weird.
[...]
The 'release.py create-tag' didn't work properly b
Daniel Shahaf wrote:
> Johan Corveleyn wrote on Mon, 16 Jul 2018 00:46 +0200:
> > It seems something went wrong with the "Post-release housekeeping"
> > commits on the 1.10.x branch, r1835806 (post 1.10.1) and r1835936
> > (post 1.10.2): they contain an empty diff for svn_version.h ... weird.
>
>
16 matches
Mail list logo
