Daniel Shahaf | 25 Jun 18:28 2016

Re: ABI changes analysis

Greg Stein wrote on Sat, Jun 25, 2016 at 07:29:11 -0500:
> I've reviewed the reports, and it looks like we've maintained all our ABI
> guarantees. The changes are what I would expect.
> 
> Thank you for this!

+1 on both counts.

Perhaps we could run this on candidate tarballs as part of the release
process?

Ponomarenko Andrey | 25 Jun 07:45 2016
Picon

ABI changes analysis

Hello,

I'm working on a new project for backward compatibility analysis of the Linux ABIs. The report for
Subversion base libraries has been recently added to the project: http://abi-laboratory.pro/tracker/timeline/subversion/

The report is generated with the help of the abi-compliance-checker, abi-dumper and abi-tracker tools: https://github.com/lvc/abi-tracker

Hope this will help users, maintainers and developers of libraries to maintain backward compatibility.

Thank you.

Johan Corveleyn | 22 Jun 01:20 2016
Picon

Cleaning up the FAQ

I think our FAQ is a bit of a mess (with all due respect to the people
who have contributed to it over the years -- time has just taken its
toll). Some questions are no longer relevant for recent releases (e.g.
documented workarounds for problems that have since been fixed; or
referring to BDB or subversion 1.0 or ...).

I'd like to clean it up a bit:
1) Move anything only relevant to old releases (anything < 1.9 or <
1.8 (?)) to a separate page (faq_old.html or something -- linked from
the main faq with a link somewhere at the top "Questions about older
releases").

2) Remove some questions that are unlikely to be relevant /
interesting anymore (e.g. "How is Subversion affected by the 2007
changes in Daylight Savings Time (DST)?")

3) Gradually rework some answers where we have a better way of explaining.

Thoughts?

I'd like to start with (1) and (2) to get at least some "less
relevant" stuff out of the way, and then do some (3)-work when / where
I feel an itch to scratch ...
Any help is greatly appreciated of course.

--

-- 
Johan

Yerra Babji | 20 Jun 09:08 2016
Picon

Which is the best tool /process to migrate VSS (with history) to Subversion

Hi,

I am looking for best tool / process to migrate VSS folders (with history ) to Subversion.

Thanks in advance for your suggestions.

Thanks,
Babji
Johan Corveleyn | 16 Jun 23:32 2016
Picon

Making working copy sparse loses local deletes / moves

Hi all,

I'm following through on a thread I started on the users list, about
"sparsifying a working copy" [1] (i.e. invoking 'svn up --set-depth
empty' on a parent directory, in order to selectively retrieve
specific children later). It looks like there is a bug when "emptying"
a directory like that, and I'd like to get some opinions here about
the expected behaviour.

When making a directory depth=empty, svn is careful not to lose local
modifications (modified files are left there as part of the sparse
working copy -- same for added files). However, local deletes are lost
(and consequently also moves are broken, only the A+ is left). It
think that's a bug, it makes it hard to confidently make a working
copy more sparse.

Copy-pasting some reproduction transcripts from the users <at> -thread below:

Sparsification breaking a move [2]:
[[[
C:\svntest>svnadmin create r

C:\svntest>svn co -q file:///c:/svntest/r wc

C:\svntest>cd wc

C:\svntest\wc>touch iota

C:\svntest\wc>svn add -q iota

C:\svntest\wc>svn ci -q -m r1

C:\svntest\wc>svn up -q

C:\svntest\wc>svn mv iota kappa
A kappa
D iota

C:\svntest\wc>svn st
D iota
> moved to kappa
A + kappa
> moved from iota

C:\svntest\wc>svn up --set-depth empty
D iota
Updating '.':
Updated to revision 1.

C:\svntest\wc>svn st
A + kappa
]]]

Sparsification losing a simple delete [3]:
[[[
C:\svntest>svn co file:///c:/svntest/r wc2
A wc2\iota
Checked out revision 1.

C:\svntest>cd wc2

C:\svntest\wc2>svn rm iota
D iota

C:\svntest\wc2>svn st
D iota

C:\svntest\wc2>svn up --set-depth empty
D iota
Updating '.':
Updated to revision 1.

C:\svntest\wc2>svn st

]]]

[1] http://svn.haxx.se/users/archive-2016-06/0064.shtml
[2] http://svn.haxx.se/users/archive-2016-06/0077.shtml
[3] http://svn.haxx.se/users/archive-2016-06/0088.shtml

--

-- 
Johan

Pavel Lyalyakin | 13 Jun 17:15 2016

Inconsistent 'show help' commands in `svn resolve` (property conflicts vs text conflicts)

Hello,

I've been checking the conflict resolution tool to make necessary adjustments to SVNBook 1.8 and noticed that text conflict resolution offers to press (s) key to show the full list of available commands (e.g. like on this screen output[*]):
[[[
show all options (s):
]]]
[[[
(s)  - show this list (also 'h', '?')
]]]
As you see, it accepts (s), (?) and (h) keys to show the list of all available commands.

However, the property conflict resolution tool has a different text and it does not accept (s) and (?) keys:
[[[
$ svn resolve Makefile
Conflict for property 'abc' discovered on 'Makefile'.
local add, incoming add upon update
Select: (p) postpone, (mf) my version, (tf) their version,
        (dc) display conflict, (e) edit property, (q) quit resolution,
        (h) help: s
Unrecognized option.
]]]
[[[
(h)  - show this help (also '?')
]]]

Was there any special reason to switch (h)elp option to (s)how all options?

IMO, both tools and the new tree conflict resolution tool have to be consistent when it comes to the commands they accept. But I'm not sure whether (h)elp is better than (s)how all options as the default key for 'help'.

[*]: http://svnbook.red-bean.com/en/1.8/svn.tour.cycle.html#idp8043776

--
With best regards,
Pavel Lyalyakin
VisualSVN Team
Paul Hammant | 11 Jun 12:37 2016

SVN-4635: Cherry-pick merge scenario causes Svn to choke

http://subversion.apache.org/docs/community-guide/issues.html amongst other things, says "
if you're pretty sure about the bug, go ahead and post directly to our development list". OK, so here's a bug with merge tracking:

   https://issues.apache.org/jira/browse/SVN-4635

   Synopsis: Series of cherry-picks between branches breaks subversions merge tracking

A reproducible bug, I should say - there's bash scripts within the issue. made on a mac and tested with Svn 1.9.4.

I even ported the same scripts to Perforce, Git and Mercurial (same sequence of merge events) and it
works fine. The code for those is on branches in that same Git repo.

- Paul
Stefan Sperling | 10 Jun 18:45 2016
Picon
Gravatar

new svn conflict resolver status update

I have been regularly working on the new conflict resolver since January.
This is a status update to present the results so far, and what remains
to be done before we can release this.

The code is on trunk, and not on a branch. We could still disable it
without much effort. However, at this point I think this feature is
worth holding the 1.10 release for, until the feature is mature enough
to be released. The lack of tree conflict resolution is a big pain point
for a huge part of our user base (at least for those who stick with
SVN in spite of this problem, for whatever reason). Now that we've got
a real chance to make a difference in that area in the next release,
I think we should.

What is basically ready are:

 - The libsvn_client API (see svn_client.h). I don't see much potential
   for changes there, apart from small cleanups.
   The model used by this API was discussed between myself, Philip, and
   Julian in Slovenia last year, and the 'svn' client has been fully
   converted over (some legacy API fragements remain, but they don't
   affect the resolver code at all).

 - More detailed description of conflicts. Most tree conflicts now describe
   the conflicting incoming and local changes in detail. The descriptions are
   actually trying to explain what happened, rather than basically dumping 
   raw working copy meta data to the screen. Users are pointed at revisions
   which contributed to the conflict, and see the author's name in the
   description. I hope this will make communication between developers
   easier when confronted with difficult merge conflicts.
   While doing consulting work for elego clients, I encountered many cases
   where digging up this information to understand where the conflict was
   coming from was harder for users than the actual resolution process itself.
   So I believe fixing this problem alone will be worth it.

 - It is now possible to add new conflict descriptions and resolution options
   to the resolver over time, without changing the public API (except for one
   place, the enum which provides public IDs for options -- but clients don't
   necessarily need this ID to provide support for an option).

 - Some basic resolution options have been implemented for cases like adds
   and deletes. Some even have regression tests.

What needs more work:

 - I'd like to offer graphical descriptions along with textual ones,
   in ASCII art and SVG (for GUI clients).
   A very-nice-to-have feature, not absolutely essential.

 - The resolver attempts to detect incoming moves based on scanning the log.
   This code is very new and experimental. I believe we will need to do a
   lot of testing before we can release this feature to the world.
   The possible edge cases are entirely unclear to me.

 - We need to add more resolution options. The more options we offer,
   the less manual conflict resolution work will have to performed by
   our users. This is really a case where we can't be adding too much,
   no matter how much we keep adding. Since we can always add more options
   in patch releases (no API change required), for 1.10 we should aim for
   a solid set of options with reasonable coverage of common cases.
   We don't have to lean ourselves too far out of the window for 1.10.0.

 - Test coverage is poor. Some XFAIL tests already show that some of the
   existing options don't work in some cases, which is a good thing (from
   the testing point of view). Apart from addressing the existing XFAIL
   tests (hairy merge problems...), we need to add a lot more tests.
   We should have at least one test per resolution option. Ideally, we'll
   test each option in all possible cases it may apply to, i.e. some subset
   of possible combinations of: forward update, backwards update, sync-merge,
   reverse-merge, reintegrate-merge, cherry-pick merge, switch going
   forward in history, switch going backwards in history, file vs file,
   file vs directory, directory vs file, directory vs directory, symlinks,
   externals, add, delete, edit, move, replacement, copy...

I am going to need help especially with the last point, simply because of
the sheer size of the problem space. The existing tests are C test for
libsvn_client, and are using the same API that clients would use.
The python test framework doesn't handle interactive prompting at the
moment so it's pretty much impossible to test the resolver with it.

Understanding the resolver implementation is not necessary when adding tests.
Understanding the resolver API, and understanding how to use the C API to
fudge a working copy into some conflicted state, is sufficient.
If I had a bunch of squirrels to train, just smart enough to know a bit
of C, I'd get a long way with this. But all alone, it's too much work.

I know that we don't have many developer resources right now, and that
many don't have time to write big features themselves these days.
I'd still like to ask for help with the above, because I think if someone
spends the little time they've got on this problem, then that's a very good
investment. With each conflict description we add, and each resolution
option we add, and a test to be certain that it's going to work well,
we're saving our users, some of who are dealing with tree conflicts every
day, a huge chunk of time when they run into the particular conflict.

Even small contributions every now and then would also help with another
problem: I'm starting to feel somewhat lonely around here. While it's great
to have a giant sandbox for myself to play in, the lack of continuous
feedback, which I had usually been receiving for as long as I'm involved
in this project, makes me uncertain about making difficult decisions
and afraid of introducing problems we can't easily fix later on.
Does anyone else feel the same way?
I realize this is normal for a project which is way past its high slope
on the hype curve, but working basically alone most of the time is a lot
less fun than I could have imagined it to be. So there's a slight danger
that I'll lose interest at some point before this project is "done".

Some things are out of scope for this project for me:

 - The resolver assumes that the conflicted node is still in the same
   structural state as the last merge/update/switch operation has left it.
   I don't think this is a huge problem for now. In many cases where
   users make manual changes to the tree structure we're clearing the
   conflict marker anyway.

 - Currently, libsvn_wc provides no new interfaces for atomic resolution
   operations (such as it does for update-move). I'm not going to work on
   this before the above problems have been addressed, if ever.
   There is no risk of inconsistent wc.db states, but automated resolution
   steps could error out at some step in the middle, in which case the user
   gets to deal with the result. However, this is arguably not worse than
   the SVN 1.9 behaviour of not even trying to resolve the conflict in
   the first place.

 - Remembering answers to previous conflicts, to avoid repeated
   interactive conflict resolution across several branches.
   This could probably be done, but I don't have a clear idea of how
   it could be implemented. In any case, it could be added later.

 - "True renames." I believe this is a dead horse, and that SVN needs
   a redesign and an entirely new implementation to support this.
   I'd be glad to be proven wrong, though.

Pavel Lyalyakin | 31 May 15:33 2016

[PATCH] SVNBook is now hosted on SourceForge, not Google Code

Hello,

README[*] still tells that SVNBook is hosted on Google Code.
The attached patch updates the README file with the correct repository URL.

Log Message:
[[[
* README
  Correct the svnbook sources URL (now hosted on SourceForge).
]]]

[*]: https://svn.apache.org/repos/asf/subversion/trunk/README

--

-- 
With best regards,
Pavel Lyalyakin
VisualSVN Team
Phil Crooker | 30 May 08:38 2016
Picon

view log problem with path authorisation

I posted this query to the users list but had no response. To me, this is not behaviour I would expect.

Authenticated users with read or r/w authorisation are unable to view logs, eg:

    # svn --username whatever --password xxxxx log svn://svn/repos/project/yada.txt
    svn: Item is not readable

After authentication, users are able to check out files, etc, just not see the logs. For anyone to view logs, I must grant anonymous read access in authz and then it works:

    [/]
        * = r 

I've seen this reported earlier but no answer:

    http://svn.haxx.se/users/archive-2011-02/0141.shtml
    http://stackoverflow.com/questions/6651997/svn-show-log-not-working


Is this a bug or is it expected behaviour?


thanks, Phil

-- --

Please consider the environment before printing this e-mail

This message from ORIX Australia may contain confidential and/or privileged information. If you are not the intended recipient, any use, disclosure or copying of this message (or of any attachments to it) is not authorised. If you have received this message in error, please notify the sender immediately and delete the message and any attachments from your system. Please inform the sender if you do not wish to receive further communications by email.

The ORIX Australia Privacy Policy outlines what kinds of personal information we collect and hold, how we collect and handle it and your rights in regards to your personal information. Our Privacy Policy is available on our website.

We do not accept liability for any loss or damage caused by any computer viruses or defects that may be transmitted with this message. We recommend you carry out your own checks for viruses or defects.

Pavel Lyalyakin | 26 May 22:15 2016

`svn help` output in SVN 1.8 and 1.9

Hello,

I'm reading through the nightly SVNBook 1.8 and make more or less
necessary changes to complete it and begin the work on SVNBook 1.9.
I've just noticed that the output of `svn help` is slightly different
in SVN 1.8 and 1.9 command-line clients.

SVN 1.8 shows the version number (take a look at the second line):
[[[
usage: svn <subcommand> [options] [args]
Subversion command-line client, version 1.8.13.
Type 'svn help <subcommand>' for help on a specific subcommand.
]]]

SVN 1.9 does not show the version number:
[[[
usage: svn <subcommand> [options] [args]
Subversion command-line client.
]]]

Was there any special reason to hide the version number here? Or is it a bug?

--

-- 
With best regards,
Pavel Lyalyakin
VisualSVN Team


Gmane