RE: general questions
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:dcchap...@acm.org] Sent: Monday, September 10, 2012 4:17 PM To: John Maher Cc: Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: general questions
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:lesmikes...@gmail.com] Sent: Monday, September 10, 2012 4:29 PM To: John Maher Cc: David Chapman; Mark Phippard; users@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. 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 lesmikes...@gmail.com
RE: general questions
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.arc...@amsi.com] Sent: Monday, September 10, 2012 5:59 PM To: John Maher; Thorsten Schöning; users@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. 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
Re: general questions
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. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: general questions
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:markp...@gmail.com] Sent: Tuesday, September 11, 2012 8:41 AM To: John Maher Cc: Bob Archer; Thorsten Schöning; users@subversion.apache.org Subject: Re: general questions 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. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: general questions
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. -- Thanks Mark Phippard http://markphip.blogspot.com/
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. 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
RE: general questions
Thanks Bob. Exactly what I was looking for. John -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, September 11, 2012 9:48 AM To: John Maher; Thorsten Schöning; users@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. 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
Re: general questions
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
RE: general questions
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:lesmikes...@gmail.com] Sent: Tuesday, September 11, 2012 11:45 AM To: John Maher Cc: David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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
Re: general questions
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 lesmikes...@gmail.com
Re: general questions
On Tue, 11 Sep 2012 12:02:51 +, 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
Re: general questions
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 lesmikes...@gmail.com
RE: general questions
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; users@subversion.apache.org Subject: Re: general questions On Tue, 11 Sep 2012 12:02:51 +, 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
Re: general questions
On Tue, 11 Sep 2012 13:11:08 +, 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 cutpase 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.
Andreas
--
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: general questions
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=poFQMAAJ The concepts still save me time every day. -- Les Mikesell lesmikes...@gmail.com
Re: general questions
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 lesmikes...@gmail.com
RE: general questions
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:lesmikes...@gmail.com] Sent: Tuesday, September 11, 2012 1:52 PM To: John Maher Cc: Andreas Krey; David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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.htm l?id=poFQMAAJ The concepts still save me time every day. -- Les Mikesell lesmikes...@gmail.com
Re: general questions
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 On Tue, Sep 11, 2012 at 9:10 PM, John Maher jo...@rotair.com wrote: 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:lesmikes...@gmail.com] Sent: Tuesday, September 11, 2012 1:52 PM To: John Maher Cc: Andreas Krey; David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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.htm l?id=poFQMAAJ The concepts still save me time every day. -- Les Mikesell lesmikes...@gmail.com
RE: general questions
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:lesmikes...@gmail.com] Sent: Tuesday, September 11, 2012 3:12 PM To: John Maher Cc: Andreas Krey; David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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 lesmikes...@gmail.com
Re: general questions
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 lesmikes...@gmail.com
Re: general questions
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.
Re: general questions
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 lesmikes...@gmail.com
Re: general questions
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: k...@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++
Re: general questions
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 lesmikes...@gmail.com
Re: general questions
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. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: general questions
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
RE: general questions
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 From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, September 10, 2012 12:35 PM To: John Maher; users@subversion.apache.org Subject: Re: general questions 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
Re: general questions
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. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: general questions
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 dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: general questions
Thank you very much. Now I can get back to reading. John From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, September 10, 2012 3:06 PM To: John Maher Cc: users@subversion.apache.org Subject: Re: general questions 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.htm l 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. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: general questions
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:dcchap...@acm.org] Sent: Monday, September 10, 2012 3:12 PM To: John Maher Cc: Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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:// 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://; http:// or https://; 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:// 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 dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: general questions
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 lesmikes...@gmail.com
Re: general questions
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.schoen...@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
RE: general questions
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:lesmikes...@gmail.com] Sent: Monday, September 10, 2012 4:05 PM To: John Maher Cc: David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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 lesmikes...@gmail.com
Re: general questions
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. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: general questions
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:tschoen...@am-soft.de] Sent: Monday, September 10, 2012 4:14 PM To: users@subversion.apache.org Subject: Re: general questions 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.schoen...@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
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. 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 lesmikes...@gmail.com
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. 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
