Re: "svn patch" and the TAB character

[Daniel Shahaf]

Daniel Shahaf wrote on Tue, 17 Dec 2019 01:55 +00:00:
> I suppose that simply trying to repeatedly s/\s+\S+$// might work well 
> enough?  That is:

In English: remove all non-whitespaces at the end of the string, then
remove all trailing whitespace.

> data = line[len('--- '):].rstrip('\n')
> need_confirmation = False
> while len(data) > 0:
> if exists(data):
> break
> else:
> data =~ s/\s+\S+$//;
> need_confirmation = True
> else:
> raise Exception("{!r} does not exist".format(line[4:]))
> if need_confirmation:
> prompt_for_confirmation(data)
>

Re: "svn patch" and the TAB character

[Daniel Shahaf]

Doug Robinson wrote on Mon, Dec 16, 2019 at 11:13:25 -0500:
> So the two file names, differing only by a TAB in the "right place" will
> currently have completely different behaviors:
> 
>   My File NameSPACE(Revision 12)
>   My File NameTAB(Revision 12)
> 
> I see no point in maintaining that the "TAB" is critically significant and
> different from the "SPACE".  The difference is easier parsing vs. 1 visually
> indistinguishable use case (depending on what tool you are using to view the
> diff file).
> 
> And the "sequence of SPACE" instead of just a single "SPACE" falls into the
> same visually indistinguishable category.  So keep the parsing simple and
> just declare file names with "SP/TAB(Revision #)" at the end to not be
> supported.

You can't assume the string after the tab will be "(revision %ld)".

First of all, as I already pointed out, that string is translatable.  Second of
all, we also have to support patches generated by third-party tools, which may
contain arbitrary text after the tab character.  And of course, both the
filename and the label (= the part after the tab character) may contain an
arbitrary number of spaces.

Please propose an algorithm for parsing a filename out of a diff header line
(a '---' line or a '+++' line) that doesn't contain tabs, under these 
conditions.
(We don't have to fix _all_ cases, but fixing the bug just for English speakers
isn't going to fly.)

---

I suppose that simply trying to repeatedly s/\s+\S+$// might work well enough?  
That is:

data = line[len('--- '):].rstrip('\n')
need_confirmation = False
while len(data) > 0:
if exists(data):
break
else:
data =~ s/\s+\S+$//;
need_confirmation = True
else:
raise Exception("{!r} does not exist".format(line[4:]))
if need_confirmation:
prompt_for_confirmation(data)

Re: [jira] [Commented] (SVN-1532) Switch a file to a dir: can't switch it back to the file

[Nathan Hartman]

On Sun, Dec 15, 2019 at 11:57 PM Daniel Shahaf  wrote:
> Nathan Hartman (Jira) wrote on Sun, 15 Dec 2019 20:12 +00:00:
> > Two different fixes have been suggested above:
> >
> > (1) Several people: Open the editor on the parent rather than the node 
> > itself.
> >
> > or
> >
> > (2) Max Oliver Bowsher: "For exactly the same reason that you cannot
> > checkout a file, you cannot switch a file. ... So, the 'fix' for this
> > issue is teach switch to maintain this invariant..."
> >
> > (Personally, Bowsher's idea makes more sense to me.)
>
> I don't see how the two cases are analogous.
>
> 'svn checkout $URL foo' creates foo/.svn/.  To do so, it requires that
> foo/ be a directory.
>
> However, it's perfectly meaningful and useful to do 'svn switch
> ^/subversion/branches/1.13.x/STATUS STATUS' in a working copy of the
> 1.13.x-r42 branch.  Moreover, why _shouldn't_ it be possible to switch a file
> to a directory?  Directory entries can be either directories or files, but 
> when we
> tell a directory that its child "iota"'s URL should be , why 
> does it
> matter whether the new URL points to a node of the same kind?

Make sense.

I've thought about this some more and one place where this might crop
up is on a Mac. The iWork office suite used to save documents as a
"package" (which appears to the user to be a file but is really a
directory full of files). I think that practice has fallen out of favor
because the newer iWork saves documents as a file by default (but can
still save/load the old "package" format, and can convert files <->
packages). Someone who has such documents under version control might
run into a switch file/directory issue.

There is already an XFAIL test for this issue. (I didn't think to look
for it until after the fact.)

(I'm looking through the issue tracker for old invalid issues that
should be closed. I haven't brought any new ones to the list in the
last couple of weeks because the issues I've tested lately are still
valid.)

> P.S. Max is a full committer, like you, so you can use first names :)

We haven't met yet. :-) But okay, less formalism later...

Cheers,
Nathan

Re: "svn patch" and the TAB character

[Doug Robinson]

On Sat, Dec 14, 2019 at 6:13 AM Stefan Sperling  wrote:

> 'svn patch' already behaves like regular patch, i.e. it assumes the whole
> line
> denotes a file name if no TAB can be found.
>
> The problem is that svn diff's revision number marker " (revision XY)" must
> be separated by a TAB. Otherwise it becomes part of the file name.
> Perhaps --patch-compatible should omit those markers?
>

The real problem is historical: poorly defined headers.
If the headers were simply:

  Something1: 
  Something2: 

Then there would be no problem.  With the current setup, the ambiguity means
that some file names are explicitly disallowed from being supported due to a
lack of disambiguating syntax (some type of quoting).  So the two file
names,
differing only by a TAB in the "right place" will currently have
completely different
behaviors:

  My File NameSPACE(Revision 12)
  My File NameTAB(Revision 12)

I see no point in maintaining that the "TAB" is critically significant and
different
from the "SPACE".  The difference is easier parsing vs. 1 visually
indistinguishable
use case (depending on what tool you are using to view the diff file).

And the "sequence of SPACE" instead of just a single "SPACE" falls into the
same visually indistinguishable category.  So keep the parsing simple and
just
declare file names with "SP/TAB(Revision #)" at the end to not be supported.

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The *LiveData* Company
*Find out more 
*wandisco.com *



 



THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: Svn server images / appliances / packages

[Mark Phippard]

On Mon, Dec 16, 2019 at 10:20 AM Julian Foad  wrote:

> Last December I observed within a blog post [1],
>
> "
>On Docker Hub [2] the most comprehensive svn server seems to be
>elleflorio/svn-server (http + svnserve). Next is garethflowers/svn-
>server (very simple; svnserve only). None seem to be an enterprise-
>grade installation.
>
>There are no 'subversion' or 'svn' packages in the SNAP store [3].
> "
>
> The packages we list on http://subversion.apache.org/packages
> are all "traditional" desktop/server operating system packages.  For svn
> server deployments, I feel we are missing some options that admins would
> prefer nowadays.
>
> Does anyone here have a good feel for what would be the most widely
> useful distribution formats nowadays?  Let's say we're talking about an
> admin installing a Subversion server for the first time, at a small to
> medium sized software development department.
>
> - Docker?
> - VM image / appliance?
> - Snap / AppImage / FlatPak?
> - ...
>
> I want to get a feel for whether we, the Subversion community [4], would
>   do well to publish one or more such option.
>
> Currently I just have a gut feeling that we should.
>


I do not think we should do it as I do not believe we are willing to hang
with it and support it. Docker would be the one to support but are we
really going to commit to keeping the image up to date and answering all of
the questions that naturally come up? I do not see how we can so it would
just be a disservice to put something out there.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Svn server images / appliances / packages

[Branko Čibej]

On 16.12.2019 16:20, Julian Foad wrote:
> Last December I observed within a blog post [1],
>
> "
>   On Docker Hub [2] the most comprehensive svn server seems to be
>   elleflorio/svn-server (http + svnserve). Next is garethflowers/svn-
>   server (very simple; svnserve only). None seem to be an enterprise-
>   grade installation.
>
>   There are no 'subversion' or 'svn' packages in the SNAP store [3].
> "
>
> The packages we list on http://subversion.apache.org/packages
> are all "traditional" desktop/server operating system packages.  For
> svn server deployments, I feel we are missing some options that admins
> would prefer nowadays.
>
> Does anyone here have a good feel for what would be the most widely
> useful distribution formats nowadays?  Let's say we're talking about
> an admin installing a Subversion server for the first time, at a small
> to medium sized software development department.
>
> - Docker?


As much as I love to hate the idea that one should deploy a whole OS
image in order to run one server app ... Docker is still the best option
given our "no binary packages" policy. Since a Dockerfile (or a
docker-compose.yaml file) is source.


> - VM image / appliance?
> - Snap / AppImage / FlatPak?
> - ...

Far too complex and/or distro-specific, IMO.


> I want to get a feel for whether we, the Subversion community [4],
> would  do well to publish one or more such option.
>
> Currently I just have a gut feeling that we should.


We should look into how, or if, other ASF projects publish their
Dockerfiles. I'd much rather have an asf/ repository at docker.io than a
subversion/ repository.

-- Brane

Re: Svn server images / appliances / packages

[Paul Hammant]

Here's one for AWS -
https://aws.amazon.com/marketplace/pp/Bitnami-Subversion-Certified-by-Bitnami/B00NN8NOAE
- but it does't meet your at home requirement.

I've run several Svn's for various at home projects. Always into Ubuntu or
Raspbian - following the setup scripts. Ten years back I put one one an
AppleTV 1.0 (after backdooring it). None particularly enterprise grade.

Svn server images / appliances / packages

[Julian Foad]

Last December I observed within a blog post [1],

"
  On Docker Hub [2] the most comprehensive svn server seems to be
  elleflorio/svn-server (http + svnserve). Next is garethflowers/svn-
  server (very simple; svnserve only). None seem to be an enterprise-
  grade installation.

  There are no 'subversion' or 'svn' packages in the SNAP store [3].
"

The packages we list on http://subversion.apache.org/packages
are all "traditional" desktop/server operating system packages.  For svn 
server deployments, I feel we are missing some options that admins would 
prefer nowadays.


Does anyone here have a good feel for what would be the most widely 
useful distribution formats nowadays?  Let's say we're talking about an 
admin installing a Subversion server for the first time, at a small to 
medium sized software development department.


- Docker?
- VM image / appliance?
- Snap / AppImage / FlatPak?
- ...

I want to get a feel for whether we, the Subversion community [4], would 
 do well to publish one or more such option.


Currently I just have a gut feeling that we should.

This is about making it easy for admins to set up Subversion in case 
they have some desire or need to do so.  I say "newly installing" 
because I suppose an admin of an existing server is unlikely to change 
their installation method.  I say a small to medium sized department 
because a large organization would more likely do things their own way 
regardless of what we provide.


To run a Subversion server for my personal use, I would currently prefer 
a Docker image.  For use at my work, we would probably choose Debian 
packages for production deployment but Docker images for development 
projects.  But I know I don't have a good feel for what is preferred in 
the sysadmin world.


Thoughts?

- Julian


[1] https://blog.foad.me.uk/2018/12/07/svn-whats-in-my-head/
[2] https://hub.docker.com/search?q=svn
[3] https://snapcraft.io/search?q=svn
[4] The ASF officially distributes source code only, but a project 
community can certainly organise distribution in other forms.