Pipe symbol causing checksum error

[Charles Humble]

I recently modified a constants file for my Java app to change the separator used for the title bar in the browser, thus:

    /**

     * Separator for title bar

     */

    public static final String TITLE_BAR_SEPARATOR = " | ";

When I try and chec the file into our SVN repository I get a checksum message.  If I change the constant to anything else it works fine.

I'm running svn --version 1.6.17 on an OS X Lion server if it helps.

Anyone aware of this?  Any workaround suggestion?

Charles

[Daniel Shahaf]

Can you copy and paste your error message to the list please? (set
'LC_ALL=C' in your environment to get it in English, if needed)

Do you use FSFS or BDB?

Does 'svnadmin verify' find any errors? (it might be interesting to try
'svnadmin verify' with a 1.7 client, though I think some changes haven't
been included in a release yet)

[John Maher]

Is svnadmin create limited to creating a local repository?

If not then how do you use it for a URL?
If so then is there a command for creating a repository via an URL? Or
is this impossible?

Thanks
JPM

[Chris Shelton]

John

On Fri, Sep 7, 2012 at 3:47 PM, John Maher <Jo...@rotair.com> wrote:
> Is svnadmin create limited to creating a local repository?

Yes.

> If not then how do you use it for a URL?

You don't.

> If so then is there a command for creating a repository via an URL? Or
> is this impossible?

It is impossible to create a repository remotely.

Read the book on repository creation:
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html

svnadmin is a server side utility to create a repository within the
local filesystem.

chris

[Bob Archer]

> John
>
> On Fri, Sep 7, 2012 at 3:47 PM, John Maher <Jo...@rotair.com> wrote:
> > Is svnadmin create limited to creating a local repository?
>
> Yes.
>
> > If not then how do you use it for a URL?
>
> You don't.
>
> > If so then is there a command for creating a repository via an URL?
> > Or is this impossible?
>
> It is impossible to create a repository remotely.

Well, strictly not true. If you have access to remote share you can create the repository on another machine.

> Read the book on repository creation:
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html
>
> svnadmin is a server side utility to create a repository within the local
> filesystem.
>

John, if you use Subversion Edge it will allow you to create repos using the Web Admin UI as well.

BOb

[Charles Humble]

Daniel,

Thanks for coming back to me.

Error message is:

svn: Commit failed (details follow):

svn: Checksum mismatch for '/path/Constants.java''; expected: 'c55ba3831fe4b9c84ed8cfa28a5b5880', actual: '8f0dd12fec0caa78fda83e5251445dad'

(I get the same error when checking in from an IDE as well as the command line but I guess the actual command and API will be the same).

Using FSFS

'svnadmin verify'  doesn't find any errors.

Charles

[John Maher]

Thanks Chris, I appreciate the link, I'm still on chapter 2. Strange it
describes creating a repository AFTER it explains properties and
commands like diff.

I read that link you posted but now I am confused about hooks. I see
the hook directory get created when I create a repository locally. But
there isn't any such directory in the repository created on a server
(VisualSVN). I searched through the book using the keyword "hooks" and
couldn't find any clue.

1) Can hooks be used on a non-local repository?
2) I read somewhere that a directory repository structure is not
recommended for multi-user environments. Is this true?
3) If #2 is true then is it also true that "svnadmin create" is for
single users ONLY?

[John Maher]

Thanks Bob.

I installed subversion edge but I don't know if it can help me or I just
can't figure it out. I can't get it to find our repositories. It won't
let me change the IP address which makes me think that it doesn't work
with non-local repositories. I searched the forums (developer and
admin) with the text "existing repositories" and found one post that
didn't match my question but it didn't matter anyway because the post
wasn't answered itself.

I was thinking about writing an html or java wrapper because command
line arguments are a thing of the past, forget about looking to the
future. Then I thought that edge does this. If it doesn't then is
there any thing else out there that may do this? For example I have to
set the svn:ignore property on 44 modules, and that is only one project.
We have other projects. Typing or editing the same command 44 times is
a bit archaic. It would be nice to type it once and click on the
modules that it applies to. I may write this myself because it would be
quicker to write a small program than type or edit the same thing over
and over again and hope I don't miss one.

John

-----Original Message-----
From: Bob Archer [mailto:Bob.A...@amsi.com]
Sent: Friday, September 07, 2012 4:03 PM
To: Chris Shelton; John Maher
Cc: us...@subversion.apache.org

[Mark Phippard]

On Mon, Sep 10, 2012 at 10:23 AM, John Maher <Jo...@rotair.com> wrote:

Thanks Bob.

I installed subversion edge but I don't know if it can help me or I just
can't figure it out.  I can't get it to find our repositories.  It won't
let me change the IP address which makes me think that it doesn't work
with non-local repositories.

Subversion Edge is a server.  It can find the local repositories on that you want it to expose.  They have to be on local disk.  It only looks in the folder you tell it the repositories are in.

The IP address in SVN Edge is also from the local server.  It is simply the local IP address whose network stats it will track.  That is it.  You configure the IP address of your server using the server OS.

 I searched the forums (developer and
admin) with the text "existing repositories" and found one post that
didn't match my question but it didn't matter anyway because the post
wasn't answered itself.

I was thinking about writing an html or java wrapper because command
line arguments are a thing of the past, forget about looking to the
future.  Then I thought that edge does this.  If it doesn't then is
there any thing else out there that may do this?

Does it do what exactly?

 

 For example I have to
set the svn:ignore property on 44 modules, and that is only one project.
We have other projects.

svn:ignore is a property you set on paths within the repository. That is something you do using a SVN client on a checked out working copy.  You then commit the property change to the repository after you set it.

 Typing or editing the same command 44 times is
a bit archaic.  It would be nice to type it once and click on the
modules that it applies to.  I may write this myself because it would be
quicker to write a small program than type or edit the same thing over
and over again and hope I don't miss one.

I cannot tell from the thread what you are trying to do.  If these are new repositories, then SVN Edge allows you to create repository templates that have content in them.  So you can setup a specific structure including things like svn:ignore settings within the repository structure and then create a template so that as you create new repositories in the future they are already setup.  The template can also include default set of hook scripts.

--
Thanks

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

[Mark Phippard]

Please keep replies on the mailing list.

On Mon, Sep 10, 2012 at 11:21 AM, John Maher <Jo...@rotair.com> wrote:

Thanks Mark.

 

Here’s what I am trying to do: learn subversion.  To do this the best I could come up with is making some test projects and going through the commands to learn them.  The problem I am having is that each step is making MORE questions than it answers.

So in a nutshell here’s three things I am currently working on:

 

1)                   Finding a client side gui.

If you are on Windows, I would start with TortoiseSVN.  If you use an IDE there are integrations like Subclipse for Eclipse and AnkhSVN for Visual Studio.

2)                   Determining the use of local and server repositories.

There is basically no such thing as a "local repository".  Repositories live on the server only.  Clients checkout from the repository which creates a "working copy".

If you haven't, the place you should be starting is the book.  It is an easy read.  You should at least read the first two chapters as many times as needed to understand them.  The rest can serve as a reference:

http://svnbook.red-bean.com/en/1.7/index.html

3)                   Prohibit programmers from stepping on each other’s ide settings.

Not sure what the issue is, but usually you can avoid committing IDE setting files.  It depends on the IDE.  I like to commit my Eclipse settings and they can usually be setup in such a way that they work for everyone.

 

(1)                 We are using VisualSVN Server so I don’t think we can use subversion edge.  A client gui would greatly enhance productivity.

VisualSVN Server and SVN Edge are both serves. So correct, you only need one of them.

(2)                 Can you use hooks on server side repositories? 

Yes.  Hooks live in the hooks folder of the repository on the server.

I see no hooks directory on the server.

Where are you looking?  When you create a repository on the server, the repository folder should contain a folder called hooks.  SVN Edge provides a web UI to manage the hooks.  I think VisualSVN has something similar in its GUI.  But you should also be able to access it via the server file system directly.

  A local repository has a hooks directory but I read somewhere that a directory based repository is not recommended for multi users and they should use a server.  Is this true?

Again, no idea what you mean by local repository.  There is only one kind of repository.  The protocol by which you access it can vary, but that is all.

 

(3)                 There are some files that are part of each module that we don’t want in the repository.  According to the book, I have to issue the same command on each directory which is not only tedious but error-prone.  I will have to manually track each directory and hope I can regain my place after each and every distraction.

Again, do not know what tool you are using.  But usually the files you want to ignore are not contained in every folder.  You can set some repository-independent ignores in the client configuration too.  For example, you can ignore all files named *.dll or *.obj etc.  This has to be configured on each client though.  svn:ignore is superior because it lives in the repository and clients get it automatically when they checkout.

[Ryan Schmidt]

On Sep 10, 2012, at 08:49, John Maher wrote:

> I read that link you posted but now I am confused about hooks. I see
> the hook directory get created when I create a repository locally.

The only way to create a repository is locally, using the "svnadmin create" command (or using some sort of GUI that someone has written on top of svnadmin). If you want to create a repository on a server, make yourself be local to the server (using ssh or screen sharing or similar) and create it there. Or find a web-based Subversion administrative GUI and install that on your server; I'm given to understand that Subversion Edge contains such a web GUI. All repositories created using "svnadmin create" will contain all the required directories, including the "hooks" directory.

$ svnadmin create foo
$ find foo -type d
foo
foo/conf
foo/db
foo/db/revprops
foo/db/revprops/0
foo/db/revs
foo/db/revs/0
foo/db/transactions
foo/db/txn-protorevs
foo/hooks
foo/locks
$

The filesystem inside the repository starts out empty, of course, for you to fill with your data as desired.

> But
> there isn't any such directory in the repository created on a server
> (VisualSVN).

I don't know what you mean by this. I'm also not familiar with VisualSVN. How did you verify that the repository on the server does not contain the hooks directory? You should be able to ssh or screenshare to the server and verify that its local filesystem has a hooks (and conf and db and locks) directory in the repository's directory.

Perhaps you're not seeing the distinction between the repository directory on the server's hard drive (which contains those directories I listed above), and what you see when you look into a repository using commands like "svn ls" or "svn checkout" (which will show whatever it is you have stored in your repository)?

> I searched through the book using the keyword "hooks" and
> couldn't find any clue.
>
> 1) Can hooks be used on a non-local repository?

The question is strange. Hook scripts run on the server. Doesn't matter whether the client accessing that server is running on the same computer as the server or on a computer halfway around the world. Users can perform actions on the repository from anywhere, and if the server has hook scripts set up for any of those actions, it will run those scripts locally on the server at the appropriate times.

> 2) I read somewhere that a directory repository structure is not
> recommended for multi-user environments. Is this true?

I'm not sure what you mean. What is a directory repository structure?

If you want to serve a collection of repositories from the same server with minimum configuration fuss, then all repositories should exist in a single directory on the server, not nested inside other subdirectories.

That is to say, your directory structure on the server should look like:

/path/to/svn/repo1
/path/to/svn/repo2
/path/to/svn/repo3

Not:

/path/to/svn/repo1
/path/to/svn/foo/bar/repo2
/path/to/svn/baz/repo3

> 3) If #2 is true then is it also true that "svnadmin create" is for
> single users ONLY?

"svnadmin create" is the only command that exists for creating repositories, therefore it is the correct command to use regardless of how those repositories will be used.

[Mark Phippard]

Please keep replies on the mailing list.

On Mon, Sep 10, 2012 at 12:02 PM, John Maher <Jo...@rotair.com> wrote:

Thanks again Mark, you have been helpful.  Let me clear some things up.

 

Let me clear up by what I mean as “local” repository.  We have a svn server which has repositories on it.  It serves us files to our local directories when we ask for them using VisualSVN Server.  I also created some repositories “locally” with svnadmin create.  The repositories are on the same machine, on the same drive as the working copy and I can get a working copy without any network access and do not need VisualSVN Server, Subversion Edge or any other server to create or access it.  Sure you can say the server is MyMachineName and the client is MyMachineName.  However the repositories ARE different because svnadmin works with one type and fails with another.  Perhaps you never used the second type.  If you have what would you call it to differentiate between them?

They are just repositories.  You can say you are accessing one via file:// protocol and one via http:// protocol if you like.

svnadmin only operates directly on the file system via the OS.  It does not talk to anything except the bytes on disk.  So it needs access to those bytes.  The normal thing to do is to run svnadmin on the server where you want your repositories to live.  You login to the server directly using something like an SSH terminal or a Remote Desktop.

When you run a GUI on your server like VisualSVN or SVN Edge, those tools are simply providing a way to run the svnadmin command via some other remote access interface such as your web browser.

 

I am still wondering about the issue I read somewhere it said you should use a what-ever-you-want-to-call-it repository via a URL and a server product (like VisualSVN Server) instead of a what-ever-you-want-to-call-it repository on a network drive without using a server product (using svnadmin create) in a multi-user environment.

You can create repositories on a network share and access them via file:// protocol but you shouldn't.  All users need full read/write access to the repository files if you do this, which means they can accidentally delete or corrupt those files.  Of course they can also do so for malicious/intentional reasons.  Accessing the repository this way will also typically be significantly slower than accessing them via a server.

And we have numerous files we need to ignore.  We are using visual studio.  We have a project which consists of 44 dlls.  Each dll is in its own directory and is a project in and of itself.  Each directory contains files and directories which need to be ignored when a new user creates a working copy so the user’s settings don’t get stepped on.  So that means entering the svn:ignore command 44 times at least for this one project alone.  I was hoping for a better way.

You can setup clients to ignore the DLL extensions always, but that has to be done on each client.  Setting svn:ignore is the better way and it only has to be done by one user and then committed to the repository for all others.

 

We do have TortiseSVN.  The documentation is quite poor with this product.

Well, I disagree.  At least compared to every other SVN client, they have the best and most complete documentation.  I cannot speak to the commercial clients, maybe some of them are better but I doubt it.

  That is the reason I am reading the book, which is NOT an easy read by the way, unless of course you already know the subject.

I think it is an easy read.  That is how I learned Subversion.  I was coming from an AS/400 background where version control is quite different.  I had used PVCS and SourceSafe quite a bit, and CVS a little bit.  From reading the book when Subversion 1.0 came out, I felt like I understood the tool almost immediately.  Obviously there was still a lot more I learned over the years by experience and this mailing list, but the book laid the ground work.  Understanding things like repositories, working copies, revisions and mixed revision working copies are all essential concepts and I think the book explains them well.

  The book jumps around worse than a bullfrog on a blacktop in the summer.  It talks about creating a repository, then goes on about properties.  I am trying to follow it but then have to change chapters because creating repositories is discussed in other places AFTER you need them to exist to test out properties.

The book is open source so feel free to suggest and contribute ideas for improvements.  It is obviously difficult to strike the right balance for giving a high level explanation of the tool and how it works, as well as comprehensive reference documentation AND cookbook like how-to.  I think it does a great job with the high-level, is fairly good for reference material and only lightly wades into the cookbook area with some of the examples.  That said, there is a ton of the cookbook type information in blogs and articles on the web now so it is not hard to find it.

 

I did find the hooks directory on the server, the VisualSVN server just doesn’t show them.

I believe they have a free and commercial version so maybe they only have this in the UI for the commercial version?  It ought to be possible to edit the files in the hooks folder and have them work either way.  Subversion Edge is free (and open source) and provides it via web UI.

[John Maher]

Thanks again, I’m learning.

 

I appreciate the time put in to help me and I really don’t want to cost you more time, so I have a couple of yes/no questions.

 

So the only time to use svnadmin create without having a dedicated server would be a single user (like me at home)?

 

As for as the dll extensions, those are not a concern.  I am talking about ide setting files.  And if we have a project made up of 44 repositories I need to enter the command 44 times, no eaiser way, right?

 

Thanks again.

John

 

---

[Mark Phippard]

On Mon, Sep 10, 2012 at 1:43 PM, John Maher <Jo...@rotair.com> wrote:

Thanks again, I’m learning.

 

I appreciate the time put in to help me and I really don’t want to cost you more time, so I have a couple of yes/no questions.

 

So the only time to use svnadmin create without having a dedicated server would be a single user (like me at home)?

Yes.  You only use svnadmin to create repositories and a few other actions that operate directly on the disk.  That means you are either managing a server or in the case of a single user, creating a personal repository on the same machine you do development.

 

As for as the dll extensions, those are not a concern.  I am talking about ide setting files.

As is noted in the book:  http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html

There is a global ignores that can be configured per client.  This lets you just ignore all files with a specific extension.  I do not know what the IDE configuration files are the you want to ignore but if they have a unique extension, this is one option.  The other option is the svn:ignore property.  This has to be set on the parent folder that might contain the files you want to ignore.  You can also ignore an entire folder, so if all your build output goes to a folder named "build" you can just ignore that entire folder.

 

  And if we have a project made up of 44 repositories I need to enter the command 44 times, no eaiser way, right?

The global ignores are a per client setting and would apply to all repositories.  You just have to make sure all your users set it up.  The svn:ignore property is set on folders within the repository.

[David Chapman]

On 9/10/2012 10:43 AM, John Maher wrote:

Thanks again, I’m learning.

 

I appreciate the time put in to help me and I really don’t want to cost you more time, so I have a couple of yes/no questions.

 

So the only time to use svnadmin create without having a dedicated server would be a single user (like me at home)?

At some level, svnadmin create will be called once per repository.  Whether that is done through a GUI-based interface or from the command line is immaterial.  This is the first step in setting up a repository, and it has to be on the machine that will serve the repository.

It may be helpful to think of Subversion as a program package that runs on a server.  If you are a single user working on a non-networked machine, then your local machine can be a Subversion server by reading the repository directly, using the "file://" protocol.  This protocol has major problems with multiple (and sometimes even remote) access, so it is safely run only on the machine where the files reside and only by one user at a time.  If you need to access a repository on another machine, particularly if multiple users will be accessing the repository, you need some kind of server process running on that machine to manage internal operations safely and arbitrate between simultaneous requests.  Subversion includes the "svnserve" program to serve files using the "svn://" protocol and has code that allows Apache HTTPD to serve files using the "http://" or "https://" protocol.

Personally, my repositories are all served using Apache HTTPD.  I have multiple machines, and although it is unlikely that I would ever commit code from two different machines at the same time, the ease of use for the "file://" protocol just wasn't worth the risk.  I host some Web sites too, and it was easier for me to adapt my HTTPD setup knowledge than to learn how to configure svnserve.  Your mileage may vary.

 

As for as the dll extensions, those are not a concern.  I am talking about ide setting files.  And if we have a project made up of 44 repositories I need to enter the command 44 times, no eaiser way, right?

 

Subversion does not provide repository administration or sandbox configuration tools; it provides a repository hosting mechanism.  What you are asking for is not part of Subversion, so yes you need to enter the command 44 times.

Scripting languages are your friends here.  Write one script to invoke the configuration commands for a single repository, then another to invoke the first script for every repository in a list.  This has multiple benefits:

1) You can call the first script each time you add a new repository, rather than type in the commands all over again.
2) Automation of this kind allows you to configure all of your repositories identically.
3) The scripts document the configuration you used (rather than scraps of paper somewhere, or the memory of an employee who may leave).

-- 
    David Chapman      dcch...@acm.org
    Chapman Consulting -- San Jose, CA
    Software Development Done Right.
    www.chapman-consulting-sj.com

[John Maher]

Thank you very much.  Now I can get back to reading.

 

John

 

---

From: Mark Phippard [mailto:mark...@gmail.com]

Sent: Monday, September 10, 2012 3:06 PM
To: John Maher

Cc: us...@subversion.apache.org
Subject: Re: general questions

 

On Mon, Sep 10, 2012 at 1:43 PM, John Maher <Jo...@rotair.com> wrote:

[John Maher]

Thanks Dave, that was helpful.

 

I saw the svn prefix in the book but didn’t know what it meant.  Your explanation was good.

 

The scripts are a good idea, but I was thinking about a gui for the client side, kinda like Subversion Edge; basically a wrapper for the command line.  Even though my first computer didn’t have a mouse (or hard drive) the gui is the way to go, typing commands is just not the future.  I may start something to make my job easier.  I think HTML would benefit the most people.  But I need to learn a lot more first.

 

John

 

 

---

From: David Chapman [mailto:dcch...@acm.org]

Sent: Monday, September 10, 2012 3:12 PM
To: John Maher

Cc: Mark Phippard; us...@subversion.apache.org
Subject: Re: general questions

 

On 9/10/2012 10:43 AM, John Maher wrote:

[Les Mikesell]

On Mon, Sep 10, 2012 at 2:31 PM, John Maher <Jo...@rotair.com> wrote:
>
> The scripts are a good idea, but I was thinking about a gui for the client
> side, kinda like Subversion Edge; basically a wrapper for the command line.
> Even though my first computer didn’t have a mouse (or hard drive) the gui is
> the way to go, typing commands is just not the future.

GUI's require the programmer to anticipate every possible thing you
might want to do and provide an elaborate user interface for it.
Command driven things can generally be combined in useful ways that
weren't initially anticipated. If you need to do some sequence of
operations on your 44 repositories, it will likely be much easier to
put the commands inside a for loop in a script than to do the
bazillion mouse clicks it will take to get to the right places in a
GUI and type them in. Unless, of course, the GUI designer
anticipated exactly that usage and gave you a way to describe it (and
then does the same loop internally...).

--
Les Mikesell
lesmi...@gmail.com

[Thorsten Schöning]

Guten Tag John Maher,
am Montag, 10. September 2012 um 21:31 schrieben Sie:

> The scripts are a good idea, but I was thinking about a gui for the
> client side, kinda like Subversion Edge; basically a wrapper for the
> command line. Even though my first computer didn't have a mouse (or
> hard drive) the gui is the way to go, typing commands is just not the
> future. I may start something to make my job easier. I think HTML
> would benefit the most people. But I need to learn a lot more first.

Don't do that, there are a lot of GUIs for Subversion out there.
Especially if you need to repeat the same task many times, the command
line and scripts are the way to got, because that's what they are made
for. Nobody wants to click the same click paths 44 times through a
GUI, that's why some programs are capable of macros. You should really
think twice if your want to waste your time with building some client
side HTML application with very limited benefit and capabilities. Have
a look at TortoiseSVN and its integration into the Windows Explorer, a
lot of mass editing tasks of whatever are really easy to achieve, as
with normale file operations.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[John Maher]

I don't 100% agree. I've designed lots of guis. And there were times
users discovered a feature I never intended. And I'm not talking about
a bug called a feature. While true that the programmer has a lot to
think about (fortunately I am one), the gui can be designed in such a
way to empower the user. Simply presenting the choices in a list will
speed use by avoiding typing in long paths and the occasional type.
Having a multi-selectable list allows any command ease of application to
many targets with a loop you spoke of. I never have to think of every
possibility the user can enter, just every possibility of a command I
will execute. They are not the same.

You are right where a script is more suitable for a sequence on many
things. My gui will never be able to compete with that. On a single
operation on many things, if the gui can do it, it will win every time.
I can out-click a very fast typer, probably not the fastest.

And if it requires a bazillion mouse clicks, it is a poor design.

John

-----Original Message-----
From: Les Mikesell [mailto:lesmi...@gmail.com]
Sent: Monday, September 10, 2012 4:05 PM
To: John Maher
Cc: David Chapman; Mark Phippard; us...@subversion.apache.org
Subject: Re: general questions

[David Chapman]

On 9/10/2012 12:31 PM, John Maher wrote:

Thanks Dave, that was helpful.

 

I saw the svn prefix in the book but didn’t know what it meant.  Your explanation was good.

 

The scripts are a good idea, but I was thinking about a gui for the client side, kinda like Subversion Edge; basically a wrapper for the command line.  Even though my first computer didn’t have a mouse (or hard drive) the gui is the way to go, typing commands is just not the future.  I may start something to make my job easier.  I think HTML would benefit the most people.  But I need to learn a lot more first.

Hmm, my first personal computer had a hexadecimal keypad and 256 bytes (not even kilobytes!) of memory.  :-)

Scripts (aka typing) allow repeatability.  A GUI that allows you to specify a set of options for every repository can be helpful, but down inside it will be doing the same thing as a script - and a script is easier to customize or debug when the existing tools don't do what you need.  Also, scripts don't disappear if the GUI goes down.  For this reason many sysadmins prefer scripts over GUI-based tools, and I don't see this ever changing.  As a result, I can't help you find a GUI that will help you administer your repositories.

TortoiseSVN is a client-side GUI for Windows-based machines but I haven't used it.  I don't know how close it comes to meeting your needs.

[John Maher]

If you think it would require 44 click paths then that is indeed a poor design.

1 click to select the repository, 1 click to select all. I just turned 44 click paths into 2 clicks. Sounds like your vision is nothing like mine.

What other guis are out there besides tortoise? If there's something I like, I'll use it. Otherwise I'll make one if only to illustrate what seems difficult for me to explain and others to grasp.

John

-----Original Message-----
From: Thorsten Schöning [mailto:tscho...@am-soft.de]
Sent: Monday, September 10, 2012 4:14 PM
To: us...@subversion.apache.org
Subject: Re: general questions

[Les Mikesell]

On Mon, Sep 10, 2012 at 3:15 PM, John Maher <Jo...@rotair.com> wrote:
> I don't 100% agree. I've designed lots of guis. And there were times
> users discovered a feature I never intended. And I'm not talking about
> a bug called a feature. While true that the programmer has a lot to
> think about (fortunately I am one), the gui can be designed in such a
> way to empower the user.

I'm not saying GUIs don't work. Just that they are generally a subset
of what can be done with commands.

> Simply presenting the choices in a list will
> speed use by avoiding typing in long paths and the occasional type.

You are making some assumptions about scale and locality here. I have
most of the world at my fingertips in the form of URLs.

> Having a multi-selectable list allows any command ease of application to
> many targets with a loop you spoke of. I never have to think of every
> possibility the user can enter, just every possibility of a command I
> will execute. They are not the same.

OK, but if I regularly work with 44 repositories, I'm likely to have
their URLs in a file where a script can extract them a lot faster than
you can navigate the world in a picklist.

> You are right where a script is more suitable for a sequence on many
> things. My gui will never be able to compete with that. On a single
> operation on many things, if the gui can do it, it will win every time.
> I can out-click a very fast typer, probably not the fastest.

Let's assume the list of choices won't fit on a screen...

> And if it requires a bazillion mouse clicks, it is a poor design.

But it can only be a good design after you already now what I'm going
to do. Until then you can only offer the bazillion choices.

--
Les Mikesell
lesmi...@gmail.com

[Ryan Schmidt]

Returning the thread to the list:

On Sep 10, 2012, at 11:18, John Maher wrote:

> Thanks Ryan.
>
> I was wrong about the hooks directory not being there, it was there just
> not displayed by VisualSVN.
>
> So if I create a repository on a network drive multiple users can use it
> if with no problems, right? If so then does that mean VisualSVN Server
> is optional?
>
> Just trying to understand subversion. Its not easy. I'm on chapter 3
> and the book is making more questions than it answers. Hopefully soon
> I'll be at the point where more questions get answered by the book than
> are created.

You should not create repositories on network drives; you could encounter [permissions|performance|corruption|dataloss] problems. Repositories should be on a disk local to the machine that's running svnserve or httpd with mod_dav_svn to serve it to users, and should be secured so that only the user that svnserve or httpd runs as can read from and write to them.

[Bob Archer]

> If you think it would require 44 click paths then that is indeed a poor design.
>

Do you really have 44 repositories? Or 44 projects in a single repository?

> 1 click to select the repository, 1 click to select all. I just turned 44 click paths
> into 2 clicks. Sounds like your vision is nothing like mine.
>
> What other guis are out there besides tortoise? If there's something I like, I'll
> use it. Otherwise I'll make one if only to illustrate what seems difficult for me
> to explain and others to grasp.

Tortoise is the best GUI for Windows I think. There are others. But, what you are doing is not a COMMON use case. The common use case it to add your ignores when you set up a new project in your repository. Doing 44 after the fact is not a standard use case.

Here is a list to some of the others:

http://svn-ref.assembla.com/windows-svn-client-reviews.html

BOb


>
> John

[John Maher]

Tortoise is pretty cool, the best out of what I tried, and I haven’t tried much.  But there are some things it can not do.

 

John

 

---

From: David Chapman [mailto:dcch...@acm.org]
Sent: Monday, September 10, 2012 4:17 PM
To: John Maher
Cc: Mark Phippard; us...@subversion.apache.org
Subject: Re: general questions

 

On 9/10/2012 12:31 PM, John Maher wrote:

[John Maher]

Interesting discussion. It appears you have not had the chance to work
with a good wrapper, or maybe you shun guis or something because there
appears to be a strong bias to your statements. I have been a
programmer AND user on both sides, gui and command line, so I am not
making things up.

> I'm not saying GUIs don't work. Just that they are generally a subset
> of what can be done with commands.

This is simply not true. Expose every function and every parameter and
there is nothing the gui can not do. Add some automation, and the gui
can actually do more.

> You are making some assumptions about scale and locality here. I have
> most of the world at my fingertips in the form of URLs.

Of course I am. I must make some assumptions or there is nothing to
talk about. Don't forget a gui can have a box where a URL is entered so
it can do everything you can by just typing in stuff plus anything else
that gets added.

> OK, but if I regularly work with 44 repositories, I'm likely to have
> their URLs in a file where a script can extract them a lot faster than
> you can navigate the world in a picklist.

Now you're making assumptions, that's OK though. Makes for a good
discussion. And you are right. Nothing works best 100% of the time.
Now think of the reverse of that. What if you wish to do something to
44 repositories once? Whats better typing them all in or clicking on
them. You can type, I'll click.

> Let's assume the list of choices won't fit on a screen...

See above reply.

> But it can only be a good design after you already now what I'm going
> to do. Until then you can only offer the bazillion choices.

Again, not true. With experience comes wisdom. Although you can never
predict a user 100% of the time, you can learn to be spot on 50% (or
better) of the time. And you seem to be forgetting a gui can do
anything text can do by offering a textbox. There's a bazillion right
there. You also have a bazillion at the command line. I think what you
are picturing is nothing like what I am planning. lol. At least I
would never use the same words to describe it as you do.

John

-----Original Message-----
From: Les Mikesell [mailto:lesmi...@gmail.com]
Sent: Monday, September 10, 2012 4:29 PM
To: John Maher
Cc: David Chapman; Mark Phippard; us...@subversion.apache.org
Subject: Re: general questions

On Mon, Sep 10, 2012 at 3:15 PM, John Maher <Jo...@rotair.com> wrote:
> I don't 100% agree. I've designed lots of guis. And there were times
> users discovered a feature I never intended. And I'm not talking
about
> a bug called a feature. While true that the programmer has a lot to
> think about (fortunately I am one), the gui can be designed in such a
> way to empower the user.

I'm not saying GUIs don't work. Just that they are generally a subset
of what can be done with commands.

> Simply presenting the choices in a list will
> speed use by avoiding typing in long paths and the occasional type.

You are making some assumptions about scale and locality here. I have
most of the world at my fingertips in the form of URLs.

> Having a multi-selectable list allows any command ease of application
to
> many targets with a loop you spoke of. I never have to think of every
> possibility the user can enter, just every possibility of a command I
> will execute. They are not the same.

OK, but if I regularly work with 44 repositories, I'm likely to have
their URLs in a file where a script can extract them a lot faster than
you can navigate the world in a picklist.

> You are right where a script is more suitable for a sequence on many
> things. My gui will never be able to compete with that. On a single
> operation on many things, if the gui can do it, it will win every
time.
> I can out-click a very fast typer, probably not the fastest.

Let's assume the list of choices won't fit on a screen...

> And if it requires a bazillion mouse clicks, it is a poor design.

[John Maher]

Thank you Ryan.

I couldn't find where I read that before and you and others explained it
well.

John

-----Original Message-----
From: Ryan Schmidt [mailto:subversi...@ryandesign.com]
Sent: Monday, September 10, 2012 5:38 PM
To: John Maher

[John Maher]

On our server we have 21 repositories. One of those repositories contains 44 projects (dlls). Each project needs the svn:ignore property set.

You're right, it is not common. But several times I had to leave tortoise to go to the command line. It's just one more pain. I feel there is a better way, I am just not sure what that way is, yet.

John

-----Original Message-----
From: Bob Archer [mailto:Bob.A...@amsi.com]

Sent: Monday, September 10, 2012 5:59 PM
To: John Maher; Thorsten Schöning; us...@subversion.apache.org
Subject: RE: general questions

> If you think it would require 44 click paths then that is indeed a poor design.
>

Do you really have 44 repositories? Or 44 projects in a single repository?

> 1 click to select the repository, 1 click to select all. I just turned 44 click paths
> into 2 clicks. Sounds like your vision is nothing like mine.
>
> What other guis are out there besides tortoise? If there's something I like, I'll
> use it. Otherwise I'll make one if only to illustrate what seems difficult for me
> to explain and others to grasp.

[Mark Phippard]

On Tue, Sep 11, 2012 at 8:32 AM, John Maher <Jo...@rotair.com> wrote:

On our server we have 21 repositories.  One of those repositories contains 44 projects (dlls).  Each project needs the svn:ignore property set.

You're right, it is not common.  But several times I had to leave tortoise to go to the command line.  It's just one more pain.  I feel there is a better way, I am just not sure what that way is, yet.

You can set properties using TortoiseSVN:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-props

You can also set properties on folders recursively.  The problem with doing this for svn:ignore is that it is a multi-line property and it would be fairly uncommon to want an identical property value for every folder.  If that is what you want, setting it would be very easy to do.

 

[John Maher]

Thanks Mark!!!  That might be exactly what I was looking for.  Now I have an unusual question I don’t know if anyone knows the answer.  I may just try it anyway.  What happens if I have more ignores than I need.  Will it hurt performance much?  For example, my setup looks like this:

 

Reporitory/Project1

Reporitory/Project1/bin

Reporitory/Project1/Graphics

Reporitory/Project1/My Project

Reporitory/Project1/obj

Reporitory/Project1/sql

Reporitory/Project2
…

Reporitory/Project44

 

What if I set this property recursively “svn:ignore *.sou *proj.user bin obj”?  I know it will get applied to many directories unnecessarily.  For example, only the top level directory (Project1) will contain any *.sou files.  The ignore will get applied everywhere, even where it is not needed.  Can this cause any major issues?  I like the idea of entering the property once.  Although I can go down the line and paste the property where it is supposed to go.  Is it worth the extra effort?

 

That is what I was looking for Mark, thanks.

 

John

 

 

---

From: Mark Phippard [mailto:mark...@gmail.com]
Sent: Tuesday, September 11, 2012 8:41 AM
To: John Maher
Cc: Bob Archer; Thorsten Schöning; us...@subversion.apache.org
Subject: Re: general questions

 

On Tue, Sep 11, 2012 at 8:32 AM, John Maher <Jo...@rotair.com> wrote:

[Mark Phippard]

On Tue, Sep 11, 2012 at 9:38 AM, John Maher <Jo...@rotair.com> wrote:

Thanks Mark!!!  That might be exactly what I was looking for.  Now I have an unusual question I don’t know if anyone knows the answer.  I may just try it anyway.  What happens if I have more ignores than I need.  Will it hurt performance much?  For example, my setup looks like this:

 

Reporitory/Project1

Reporitory/Project1/bin

Reporitory/Project1/Graphics

Reporitory/Project1/My Project

Reporitory/Project1/obj

Reporitory/Project1/sql

If this were me, I would have an svn:ignore on my Project1 folder that ignores the bin and obj folder.  That would cause everything inside those folders to also be ignored.

For other folders, I could then add specific file patterns only if needed. Odds are I would have all my build output in bin and obj though so probably not a lot else to ignore.

What if I set this property recursively “svn:ignore *.sou *proj.user bin obj”?  I know it will get applied to many directories unnecessarily. 

I do not think it will cause any performance issues at all.  That said, it seems like those ignores would only need to be applied on the project root folder.  If you have bin and obj folders being created all over the place it seems like you ought to fix that.

 

For example, only the top level directory (Project1) will contain any *.sou files.  The ignore will get applied everywhere, even where it is not needed.  Can this cause any major issues?

No.

 

  I like the idea of entering the property once.  Although I can go down the line and paste the property where it is supposed to go.  Is it worth the extra effort?

Setting svn:ignore is pretty much a one-time deal. That is why you are not going to find many tools to automate.  There is no payoff in spending the time to write such a tool.  I personally do not like seeing the property set where it is not needed or with values that are not needed.  It does not cause performance problems, it just adds "noise".  I do not believe manually setting up the property is a lot of work.  Even if it is 44 projects.  I would just set it up and deal with it as needed.

[Bob Archer]

> > If you think it would require 44 click paths then that is indeed a poor design.
> >
>
> Do you really have 44 repositories? Or 44 projects in a single repository?
>
> > 1 click to select the repository, 1 click to select all. I just
> > turned 44 click paths into 2 clicks. Sounds like your vision is nothing like
> mine.
> >
> > What other guis are out there besides tortoise? If there's something
> > I like, I'll use it. Otherwise I'll make one if only to illustrate
> > what seems difficult for me to explain and others to grasp.
>
> Tortoise is the best GUI for Windows I think. There are others. But, what you
> are doing is not a COMMON use case. The common use case it to add your
> ignores when you set up a new project in your repository. Doing 44 after the
> fact is not a standard use case.
>
> Here is a list to some of the others:
>
> http://svn-ref.assembla.com/windows-svn-client-reviews.html
>
> BOb
>
>
> >
> > John

> On our server we have 21 repositories. One of those repositories contains 44
> projects (dlls). Each project needs the svn:ignore property set.
>
> You're right, it is not common. But several times I had to leave tortoise to go
> to the command line. It's just one more pain. I feel there is a better way, I
> am just not sure what that way is, yet.
>
> John
>

Tortoise lets you apply properties recursively.

If you want to apply the property to every file and folder in the hierarchy below the current folder, check the Recursive checkbox.

Check the tortoise help: 4.17.1.2. Adding and Editing Properties

BOb

[John Maher]

Thanks Bob. Exactly what I was looking for.

John

-----Original Message-----
From: Bob Archer [mailto:Bob.A...@amsi.com]
Sent: Tuesday, September 11, 2012 9:48 AM
To: John Maher; Thorsten Schöning; us...@subversion.apache.org
Subject: RE: general questions

[Les Mikesell]

On Tue, Sep 11, 2012 at 7:22 AM, John Maher <Jo...@rotair.com> wrote:
> Interesting discussion. It appears you have not had the chance to work
> with a good wrapper, or maybe you shun guis or something because there
> appears to be a strong bias to your statements.

First, let me remind you that you started the discussion, complaining
about not being able to find the way to do what you wanted in a GUI.

> I have been a
> programmer AND user on both sides, gui and command line, so I am not
> making things up.

I'm more of a system administrator, so used to doing things that
aren't designed into GUIs as everyday operations for most users.

>> I'm not saying GUIs don't work. Just that they are generally a subset
>> of what can be done with commands.
>
> This is simply not true. Expose every function and every parameter and
> there is nothing the gui can not do. Add some automation, and the gui
> can actually do more.

But that's within a single application. Well designed command line
tools and scripting languages include all of each others'
functionality fairly seamlessly. While a GUI 'could' let me run a
program of my choice to supply any option or input, none that I've
seen actually do. So they are limited to what the designer
anticipated where the command line tools gain functionality as new
tools are developed or you add your own helper/wrapper scripts.

>> You are making some assumptions about scale and locality here. I have
>> most of the world at my fingertips in the form of URLs.
>
> Of course I am. I must make some assumptions or there is nothing to
> talk about. Don't forget a gui can have a box where a URL is entered so
> it can do everything you can by just typing in stuff plus anything else
> that gets added.

But, I said I would have a list of URLs in a file. Your GUI 'could'
let me provide the file as input. But that would be a rare choice for
a GUI designer and a common scenario for me. So if forced to use a
gui for a repeated operation, I'd probably end up displaying the file
in one window and cutting/pasting a line at a time as I repeat the
many mouse-clicks it might take for the rest of the work.

>> OK, but if I regularly work with 44 repositories, I'm likely to have
>> their URLs in a file where a script can extract them a lot faster than
>> you can navigate the world in a picklist.
>
> Now you're making assumptions, that's OK though. Makes for a good
> discussion. And you are right. Nothing works best 100% of the time.
> Now think of the reverse of that. What if you wish to do something to
> 44 repositories once? Whats better typing them all in or clicking on
> them. You can type, I'll click.

My assumptions are from past history. Picking 44 names out of 100
might be a win. Picking 44 out of 50,000, I'd rather just type them
in, but if I am creating a new, arbitrary set of names for related
things I'd use a name convention where wildcards or number sequences
make the set script-friendly for operations on the group. If someone
else has given me the names, we are back to already having the list in
a file and the script just has to iterate over it.

>> But it can only be a good design after you already now what I'm going
>> to do. Until then you can only offer the bazillion choices.
>
> Again, not true. With experience comes wisdom.

How does that differ from what I said? If the GUI designer knows
what I'm going to do and wants to spend the time making it easier,
then yes, the GUI approach can be nicer. But if I want to do
something new and different (and what's the point if I don't?) then
combining all of the functionality of existing commands with script
wrappers and a few of my own is going to win.

> Although you can never
> predict a user 100% of the time, you can learn to be spot on 50% (or
> better) of the time. And you seem to be forgetting a gui can do
> anything text can do by offering a textbox.

No, a textbox is not the same at all. Text tools allow running any
program you want to expand the result. I suppose a textbox 'could'
let you put in $(cat wild_card_filename) or $(grep pattern filename)
and accept the result like any bash command line will, but I've never
seen a GUI do that.

> There's a bazillion right
> there.

But that's a bazillion you have to input There's an old saying that
GUI's make 'easy things easier and difficult things impossible'.

> You also have a bazillion at the command line.

Which can be generated by any other tool at my disposal.

> I think what you
> are picturing is nothing like what I am planning. lol. At least I
> would never use the same words to describe it as you do.

OK, but I spent a couple of days 20+ years ago learning how to combine
the work of different tools with simple shell scripting and it has
saved me time pretty much every day since. But, I tend to think that
the best user interface is no interface at all - that is, the machines
should just do your work for you in the cases where it is predictable,
and it should be trivial to repeat complex sequences even when you
have to do it manually. If you have to do some set of operations
across 44 instances of something today, how will your GUI help you
automate that set of operations on the next 44? If you did it on the
command line, you'd just recall the command and edit the target. Or
save it in a file that you can edit easily, or come up with a way
another tool can generate the target list. The 'graphic display' of
the operation isn't particularly useful on its own here - you just
want the underlying work done.

--
Les Mikesell
lesmi...@gmail.com

[John Maher]

Sorry Les, you just don't get it. Just because you've never seen
something doesn't mean it can't or shouldn't be done. Its sad that you
haven't seen any good tools. You make the same mistake over and over
assuming that a wrapper designer anticipates what the user wants to do.
While that may be true in an application that is definitely not
necessary in a wrapper, and not desired. If a programmer based thier
logic on that assumption, they would always be wrong. A good wrapper
"wraps" the functionality of the command line to a guid, initially there
is no anticipation or user actions. A good wrapper would only
anticipate AFTER all functionality has been accounted for, this
anticipation would be for features that do not exist in the command line
AFTER all functions and parameters are already passed from the gui to
the command line. So there is NOTHING the gui can't do that the command
line can except take more time to do something. You're confusing the
steps to design an application with the steps to design a wrapper. Two
different animals and if you mix the two its like trying to pull a
trailer with a corvette. It may work, it may cause problems. It
definitely is not optimal.

John

-----Original Message-----
From: Les Mikesell [mailto:lesmi...@gmail.com]
Sent: Tuesday, September 11, 2012 11:45 AM
To: John Maher
Cc: David Chapman; Mark Phippard; us...@subversion.apache.org
Subject: Re: general questions

[Les Mikesell]

On Tue, Sep 11, 2012 at 11:02 AM, John Maher <Jo...@rotair.com> wrote:

> So there is NOTHING the gui can't do that the command
> line can except take more time to do something.

What they don't do is let me build on things that already work in
arbitrary ways (especially in other languages and on other
machines...), and add to that when I have anything else that works.
Maybe they could, but then they would become a programming language
themselves.

> You're confusing the
> steps to design an application with the steps to design a wrapper. Two
> different animals and if you mix the two its like trying to pull a
> trailer with a corvette. It may work, it may cause problems. It
> definitely is not optimal.

That's fine if you want to buy a new vehicle for everything you
transport, never re-using anything you've done or being able to expand
on it because you need a self-contained application for every
operation. But, I like being able to do something once, then repeat
it across a hundred machines with a simple script loop wrapping ssh.
Or schedule it to run automatically. Or use some other remote tool
to generate some of the options and/or inputs. Each tool does a step
optimally and repeatably. Can you really beat what ssh does - or even
grep?

--
Les Mikesell
lesmi...@gmail.com

[Andreas Krey]

On Tue, 11 Sep 2012 12:02:51 +0000, John Maher wrote:
...

> line can except take more time to do something. You're confusing the
> steps to design an application with the steps to design a wrapper.

You're confusing a single application with the whole command line
and *everything* it can invoke. In your picture that whole set of all
commands available now or in the future is the 'the application' for
which you'd need to design a GUI, would you want to have its flexibility
available in a GUI.

> different animals and if you mix the two its like trying to pull a
> trailer with a corvette. It may work, it may cause problems. It
> definitely is not optimal.

That's because a corvette isn't designed for a trailer hook. That
is exactly the situation with all kinds of GUis: Interaction
with *other* applications (the trailer) isn't designed in,
and can't be automated.

GUI applications are designed to interact with a user, and not with
other applications, and that is their general deficiency for some
kinds of work.

Try to get you browser and photoshop to play together and download,
scale, and publish a webcam pic every hour, and you see the non-power
of the GUI.

Andreas

--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

[John Maher]

> What they don't do is let me build on things that already work in
> arbitrary ways (especially in other languages and on other
> machines...), and add to that when I have anything else that works.
> Maybe they could, but then they would become a programming language
> themselves.

Actually, they can Les and would not become a programming language
themselves, that's what states and return codes are for. And you can
call programs from other programs, but that's beyond the scope of the
task. Actually you're blowing this all out of proportion. I'm talking
about a simple wrapper to streamline actions normally required by
issuing commands. You're thinking of my tool for your job, it won't
work. It won't even work for my job, it will not write code. My tool
will work for part of my job, just like the issued commands that it
would replace.

> That's fine if you want to buy a new vehicle for everything you
> transport,

Again, you miss the point. You don't but a new vehicle for everything
you wish to transport. You buy 1 truck to do the transporting. It has
noting to do with re-using. In fact, programming is all about reusing.
I would be reusing lots of stuff. You can re-use everything either way.
I can call grep or anything else, it is irrelevant. It is simply a
different way to input something. That's it. Nothing more. Any extra
stuff you pile on top will only confuse you. You don't have to like
guis or programmers. But to say they are not useful or detrimental is a
prejudice that can hurt you because it frankly is not a fact.

-----Original Message-----
From: Les Mikesell [mailto:lesmi...@gmail.com]
Sent: Tuesday, September 11, 2012 12:30 PM
To: John Maher
Cc: David Chapman; Mark Phippard; us...@subversion.apache.org
Subject: Re: general questions

[Les Mikesell]

On Tue, Sep 11, 2012 at 11:48 AM, John Maher <Jo...@rotair.com> wrote:
> You don't have to like
> guis or programmers. But to say they are not useful or detrimental is a
> prejudice that can hurt you because it frankly is not a fact.

I've never said they weren't useful. I've said that they restrict you
to what the designer allows you to do. If that is all you ever want
to do, then they are great. However, in many years of system
administration, I have not found that to be the general case.

--
Les Mikesell
lesmi...@gmail.com

[John Maher]

> You're confusing a single application with the whole command line
> and *everything* it can invoke. In your picture that whole set of all
> commands available now or in the future is the 'the application' for
> which you'd need to design a GUI, would you want to have its
flexibility
> available in a GUI.

I don't understand this statement at all. I'm talking about a simple
wrapper. And it would be very easy in incorporate *everything*. Even
command that have not been added yet.

> Interaction with *other* applications (the trailer) isn't designed in,
> and can't be automated.

Again, if necessary it can be, very easy. However that is not the point
of the wrapper. If I want to build a car you can say but it can't fly.
And it can't float. You're right. It isn't supposed to. You can
always pick fault about something if you go beyond its scope.

> GUI applications are designed to interact with a user, and not with
> other applications

Again that is not true. Well the first part is. The second part (("not
with other applications") may or may not be true. Depends on the app.
I'm starting to learn who isn't a programmer because they have common
misconceptions about how programs are designed. I wonder if its from
watching TV? Or maybe designing a system is so rigid that its difficult
to comprehend the freedom allowed in designing a program. They are not
as limited as you believe them to be.


John

-----Original Message-----
From: Andreas Krey [mailto:a.k...@gmx.de]
Sent: Tuesday, September 11, 2012 12:57 PM
To: John Maher

Cc: Les Mikesell; David Chapman; Mark Phippard;
us...@subversion.apache.org
Subject: Re: general questions

[Andreas Krey]

On Tue, 11 Sep 2012 13:11:08 +0000, John Maher wrote:
...

> I don't understand this statement at all. I'm talking about a simple
> wrapper.

Ok, I got that wrong. But exactly for those wrappers there is no point in
trying to do *everything* the CLI can do in the GUI as well. Streamline
the most important things. I've done such a thingie for myself for cvs;
you could just run update (where in svn you'd do status), click on
filenames to see the diff, and commit. Nothing more needes; the only
point was not to cut&pase the filenames.

Interestingly I do the same with git on the command line because those
tools have gotten better and more streamlined there.

> And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.

You can't especially not shell invocations, as that would viod the spriti
of the GUI.

> Again, if necessary it can be, very easy. However that is not the point
> of the wrapper.

Yes, it is. Imagine a GUI for 'svn status'. Now imagine how you'd
do the equivalent of 'svn status | awk '/I / { print $2 } | xargs rm'
with that GUI, or even with the help of that GUI for the svn part.

Putting that in a script and name it svn-clean is two lines.
Putting that in a GUI (and esp. your svn status wrapper) is..how much?

...

> in designing a program. They are not
> as limited as you believe them to be.

Programs aren't. GUIs are, exactly because of their primary goal.
They want to avoid the plugs and bolts at the outside, and thus they
aren't pluggable and boltable. (And yes, they do make many things
easier. And other things impossible.) Even Word has a CLI; even
though it's gruesome and called word basic.

[Les Mikesell]

On Tue, Sep 11, 2012 at 12:11 PM, John Maher <Jo...@rotair.com> wrote:
>> You're confusing a single application with the whole command line
>> and *everything* it can invoke. In your picture that whole set of all
>> commands available now or in the future is the 'the application' for
>> which you'd need to design a GUI, would you want to have its
> flexibility
>> available in a GUI.
>
> I don't understand this statement at all. I'm talking about a simple
> wrapper. And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.

On the command line, every piece of text, including the base command
to run can be the expansion of shell variables, file wildcards, or the
output of any other program. If a GUI offers any of those options
you pretty much lose any point/click advantage it might have since the
choices approach infinity. The input can be the output of any other
program. If the tool doesn't do the complete job, the output can go
to any other tool.

>> Interaction with *other* applications (the trailer) isn't designed in,
>> and can't be automated.
>
> Again, if necessary it can be, very easy. However that is not the point
> of the wrapper. If I want to build a car you can say but it can't fly.
> And it can't float. You're right. It isn't supposed to. You can
> always pick fault about something if you go beyond its scope.

That's the point here. Things based on text stream processing don't
have 'scopes' or associated limits. Likewise for command lines based
on text expansions.

>> GUI applications are designed to interact with a user, and not with
>> other applications
>
> Again that is not true. Well the first part is. The second part (("not
> with other applications") may or may not be true. Depends on the app.
> I'm starting to learn who isn't a programmer because they have common
> misconceptions about how programs are designed. I wonder if its from
> watching TV?

Starting here worked out pretty well for me:
http://books.google.com/books/about/The_UNIX_programming_environment.html?id=poFQAAAAMAAJ
The concepts still save me time every day.

--
Les Mikesell
lesmi...@gmail.com

[John Maher]

> But exactly for those wrappers there is no point in
> trying to do *everything* the CLI can do in the GUI as well

I disagree. The point is to make the job easier. Having to switch
around would prove the point that it is not helping much. I agree to
streamline what needs to be done. But I also would want to be able to
pass any text to svn that I want. That gives me the best of both
worlds. I get the simplicity of the gui and also get to enter anything
I want, even " status | awk '/I / { print $2 } | xargs rm" by just
typing it in and passing it to svn. Not only does that handle things
that would be unfeasible it keeps things consistent. Perhaps you need
to be a system programmer to understand.

A script is just a subset of a full fledged program. In other words, a
program can do all a script can do and more. I bet other users on this
list are getting a good laugh at this discussion. I know I am!!

Your turn.

John



-----Original Message-----
From: Andreas Krey [mailto:a.k...@gmx.de]
Sent: Tuesday, September 11, 2012 1:36 PM
To: John Maher
Cc: Les Mikesell; David Chapman; Mark Phippard;
us...@subversion.apache.org
Subject: Re: general questions

[Les Mikesell]

On Tue, Sep 11, 2012 at 1:57 PM, John Maher <Jo...@rotair.com> wrote:
>>
> A script is just a subset of a full fledged program. In other words, a
> program can do all a script can do and more.

That's the part you don't seem to be getting. A script is a wrapper
around all of your programs and becomes a superset of all of them. At
least the ones that are capable of using and generating text. It is
not just limited to what any single program can do - or what is on any
single machine for that matter assuming you have a tool like ssh
available. At least that's the unix-inspired way of thinking.
Maybe you are used to some more restricted form of scripting.

--
Les Mikesell
lesmi...@gmail.com

[John Maher]

lol. These rants are priceless!! I talk about a simple wrapper and we
get text stream processing!! Tack on irrelevant things to make your
point sound good!! If you gotta reach that far then that is a clue your
argument lacks merit. I give up trying to explain it.

Sorry I'm not reading anything on unix if I can help it. Text based
operating systems will be obsolete. I know all you text gurus will
argue to your death. But JCL was junk while it was still in use. It
was used only because that had to, not because it was any good. Command
line interfaces, text based oses and the mouse are all going bye-bye.
Its just a matter of time. May be in my lifetime, may not be, I don't
care. I am focusing my attention on the future, not the past otherwise
I could get a high paying job doing cobol since those guys are in
demand. But I don't want to work with a dead language even if it won't
die in my lifetime. I'm looking ahead.


For example:

> If a GUI offers any of those options
you pretty much lose any point/click advantage it might have since the
choices approach infinity.

Wrong. A gui has textboxes. You only need to click some things, not
evey single parmeter for every single command. No wonder you don't like
guis.

> Things based on text stream processing don't
have 'scopes' or associated limits.

Wrong. If a program doesn't have a scope its unlikely to come out well.
And a program can easily accept a text stream and return one. How do
you think your commands work? They are programs.

-----Original Message-----
From: Les Mikesell [mailto:lesmi...@gmail.com]

Sent: Tuesday, September 11, 2012 1:52 PM
To: John Maher
Cc: Andreas Krey; David Chapman; Mark Phippard;
us...@subversion.apache.org
Subject: Re: general questions

[Johan Corveleyn]

Guys, guys ... take a deep breath and calm down a little bit please.
This discussion doesn't seem to be all that useful. You both really
have vastly different opinions, I don't think all this arguing is
going to change much. And it has become mostly off topic for this
mailinglist.

--
Johan

[John Maher]

>A script is a wrapper around all of your programs and becomes a
superset of all of them.

lololol that has got to be the most unusual definition I have ever
heard of a script. According to your definition, a macro in a word
processer is a superset of the entire word processer. I disagree.

Using text is not a requirement of a wrapper!! This is getting funnier
and funnier.

> Maybe you are used to some more restricted form of scripting.

Nope. I am not a scripter. I am a programmer. We use terms
consistently otherwise confusion would result. We have to communicate
with each other and work together so when we use terms like "wrapper" it
generally means the same thing. We can have a wrapper to encapsulate
code, redefine the api, but I never, ever heard of a list of command
(script) called a wrapper.

What else ya gat?

John

-----Original Message-----
From: Les Mikesell [mailto:lesmi...@gmail.com]

Sent: Tuesday, September 11, 2012 3:12 PM
To: John Maher
Cc: Andreas Krey; David Chapman; Mark Phippard;
us...@subversion.apache.org
Subject: Re: general questions

[Les Mikesell]

On Tue, Sep 11, 2012 at 2:10 PM, John Maher <Jo...@rotair.com> wrote:

> Text based
> operating systems will be obsolete.

Errr, what? Have google, amazon, facebook, etc. all changed while I
wasn't looking?

> But JCL was junk while it was still in use.

So what does that have to do with bourne shell or bash or the
underlying tools they can drive?

> was used only because that had to, not because it was any good. Command
> line interfaces, text based oses and the mouse are all going bye-bye.
> Its just a matter of time. May be in my lifetime, may not be, I don't
> care. I am focusing my attention on the future, not the past otherwise
> I could get a high paying job doing cobol since those guys are in
> demand. But I don't want to work with a dead language even if it won't
> die in my lifetime. I'm looking ahead.

I suspect quite a lot of the world would come to a grinding halt if
the commands executed by bourne-like shells stopped working - and
that's likely to be true for years to come. You'd even find more
than a little of it in OSX if you look under the covers.

--
Les Mikesell
lesmi...@gmail.com

[Andy Levy]

On Tue, Sep 11, 2012 at 3:10 PM, John Maher <Jo...@rotair.com> wrote:

> Sorry I'm not reading anything on unix if I can help it. Text based
> operating systems will be obsolete. I know all you text gurus will
> argue to your death. But JCL was junk while it was still in use. It
> was used only because that had to, not because it was any good. Command
> line interfaces, text based oses and the mouse are all going bye-bye.
> Its just a matter of time. May be in my lifetime, may not be, I don't
> care. I am focusing my attention on the future, not the past otherwise
> I could get a high paying job doing cobol since those guys are in
> demand. But I don't want to work with a dead language even if it won't
> die in my lifetime. I'm looking ahead.

You might want to "look ahead" to Windows Server 2012. The core
installation has no GUI, and the entire OS - your whole Windows
domain - can be administered via the very thing you're railing against
- a command-line interface.

Or "look ahead" to Exchange 2007, which shipped with almost no GUI to
speak of as well - any GUI it had was a wrapper on top of PowerShell
scripts (again, you did your administration via the command line).

Windows administrators & developers who choose not to get on the
PowerShell train will be left behind. The GUI is not the end-all,
be-all of computer interfaces, despite what you may believe.

[Les Mikesell]

On Tue, Sep 11, 2012 at 2:20 PM, John Maher <Jo...@rotair.com> wrote:
>>A script is a wrapper around all of your programs and becomes a
> superset of all of them.
> lololol that has got to be the most unusual definition I have ever
> heard of a script. According to your definition, a macro in a word
> processer is a superset of the entire word processer. I disagree.

OK, now I guess I understand why you had such a problem with repeating
something simple 44 times.

"Those who don't understand Unix are condemned to reinvent it,
poorly." – Henry Spencer

--
Les Mikesell
lesmi...@gmail.com

[Dave Huang]

On Tue, Sep 11, 2012 at 03:10:57PM -0400, John Maher wrote:
> Sorry I'm not reading anything on unix if I can help it.

With that statement, you've made it obvious that you don't actually
understand the capabilities of the CLI. Both CLI and GUI have their
uses, and it's definitely not the case that a GUI can do everything a
CLI can do (unless you kludge in CLI-like functionality into your
GUI... a textbox where you can type a CLI command isn't actually a
GUI; nobody considers xterm or Konsole or MacOS Terminal.app a "GUI").
(And conversely, there are certainly things that are much more easily
done with a GUI than a CLI).
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

[John Maher]

So you think 100 years from now people will be entering text based
commands? I disagree. And some people still ride horses today for
transportation. Doesn't mean I'm gonna get one. But that's OK, because
of the people needing horses it gives people who know how to groom
horses a job, which is a good thing. Just not for me.

And I don't have a lot of faith in windows retaining its market share.

Enjoy

John

-----Original Message-----
From: Andy Levy [mailto:andy...@gmail.com]
Sent: Tuesday, September 11, 2012 3:29 PM
To: John Maher
Cc: us...@subversion.apache.org
Subject: Re: general questions

[Les Mikesell]

On Tue, Sep 11, 2012 at 2:33 PM, John Maher <Jo...@rotair.com> wrote:
> So you think 100 years from now people will be entering text based
> commands?

Yes, for as long as people think, speak, write and read text, they
will use it to communicate with each other and the machines that
assist them. And they will continue to find it useful to have
programs that parse and interpret text as steps in complex operations.
As monolithic programs become more complex and complete, there may be
less use for toolset based programming at least for routine things,
though.

> I disagree. And some people still ride horses today for
> transportation. Doesn't mean I'm gonna get one. But that's OK, because
> of the people needing horses it gives people who know how to groom
> horses a job, which is a good thing. Just not for me.

To get back to the topic of subversion, think about how 'svn diff' is
useful with versions of anything that is composed of text, and much
less so with anything else. If you do something complicated in
CLI/text scripts you can just commit them to subversion and easily
track the changes you've made over time. How do you track the inputs
you've made into GUI checkboxes/selections, etc. when you need to
repeat or audit something or see how things were done differently over
a several-year span?

--
Les Mikesell
lesmi...@gmail.com