bug
"Error: database is locked, executing statement 'COMMIT
TRANSACTION;'" . One hundred times per day. It's very big headache.
Error occures while getting updates from repo.
After error I'll getting this error while try to clean up my locked
local copy. A lot of tryings solve this problem,
but for a short time.
TortoiseSVN version info: TortoiseSVN 1.7.9, Build 23248 - 64 Bit ,
2012/08/30 18:25:37
--
Maliavko, Igor
WOT Development User Interface Programmer
Wargaming.net | GameStream
Email: i_malia...@wargaming.net
skype: igor.maliavko
ICQ: 447129753
Phone: +375-298437996
--
System Information
--
Time of this report: 9/11/2012, 13:22:11
Machine name: I-MALIAVKO
Operating System: Windows 7 Ultimate 64-bit (6.1, Build 7601) Service Pack 1
(7601.win7sp1_gdr.120503-2030)
Language: Russian (Regional Setting: Russian)
System Manufacturer: Gigabyte Technology Co., Ltd.
System Model: To be filled by O.E.M.
BIOS: BIOS Date: 03/23/12 19:41:27 Ver: 04.06.05
Processor: Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz (4 CPUs), ~3.5GHz
Memory: 4096MB RAM
Available OS Memory: 4060MB RAM
Page File: 2671MB used, 5446MB available
Windows Dir: C:\Windows
DirectX Version: DirectX 11
DX Setup Parameters: Not found
User DPI Setting: Using System DPI
System DPI Setting: 96 DPI (100 percent)
DWM DPI Scaling: Disabled
DxDiag Version: 6.01.7601.17514 64bit Unicode
DxDiag Notes
Display Tab 1: No problems found.
Sound Tab 1: No problems found.
Input Tab: No problems found.
DirectX Debug Levels
Direct3D:0/4 (retail)
DirectDraw: 0/4 (retail)
DirectInput: 0/5 (retail)
DirectMusic: 0/5 (retail)
DirectPlay: 0/9 (retail)
DirectSound: 0/5 (retail)
DirectShow: 0/6 (retail)
---
Display Devices
---
Card name: NVIDIA GeForce GTX 550 Ti
Manufacturer: NVIDIA
Chip type: GeForce GTX 550 Ti
DAC type: Integrated RAMDAC
Device Key: Enum\PCI\VEN_10DEDEV_1244SUBSYS_REV_A1
Display Memory: 2751 MB
Dedicated Memory: 977 MB
Shared Memory: 1773 MB
Current Mode: 1920 x 1080 (32 bit) (60Hz)
Monitor Name: BenQ GL2240 (Digital)
Monitor Model: BenQ GL2240
Monitor Id: BNQ7887
Native Mode: 1920 x 1080(p) (60.000Hz)
Output Type: DVI
Driver Name:
nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
Driver File Version: 8.17.0013.0142 (English)
Driver Version: 8.17.13.142
DDI Version: 11
Driver Model: WDDM 1.1
Driver Attributes: Final Retail
Driver Date/Size: 5/15/2012 13:48:00, 18044224 bytes
WHQL Logo'd: n/a
WHQL Date Stamp: n/a
Device Identifier: {D7B71E3E-5104-11CF-3E63-0D201FC2C535}
Vendor ID: 0x10DE
Device ID: 0x1244
SubSys ID: 0x
Revision ID: 0x00A1
Driver Strong Name:
oem26.inf:NVIDIA_SetA_Devices.NTamd64.6.1:Section015:8.17.13.142:pci\ven_10dedev_1244
Rank Of Driver: 00E60003
Video Accel: ModeMPEG2_A ModeMPEG2_C ModeVC1_C ModeWMV9_C
Deinterlace Caps: {6CB69578-7617-4637-91E5-1C02DB810285}:
Format(In/Out)=(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,0)
Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY
DeinterlaceTech_PixelAdaptive
{F9F19DA5-3B09-4B2F-9D89-C64753E3EAAB}:
Format(In/Out)=(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,0)
Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY
{5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}:
Format(In/Out)=(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,0)
Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY
{335AA36E-7884-43A4-9C91-7F87FAF3E37E}:
Format(In/Out)=(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,0)
Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY
DeinterlaceTech_BOBVerticalStretch
{6CB69578-7617-4637-91E5-1C02DB810285}:
Format(In/Out)=(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,0)
Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY
DeinterlaceTech_PixelAdaptive
{F9F19DA5-3B09-4B2F-9D89-C64753E3EAAB}:
Format(In/Out)=(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,0)
Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY
{5A54A0C9-C7EC-4BD9-8EDE-F3C75DC4393B}:
Format(In/Out)=(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,0)
Caps=VideoProcess_YUV2RGB VideoProcess_StretchX VideoProcess_StretchY
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: svnadmin
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:subversion-20...@ryandesign.com] Sent: Monday, September 10, 2012 5:38 PM To: John Maher Cc: Subversion Users Subject: Re: svnadmin 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.
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: Question's about install subversion server in a NAS (network attached storage).
Your repository should not be placed on a network share to be accessed via CIFS/SMB/what have you. Whether you can install an SVN server on your NAS depends upon the NAS. Some vendors offer packages which you can install on their devices to provide this sort of functionality. Check with your NAS vendor. On Tue, Sep 11, 2012 at 8:47 AM, e-friend_partner fca...@gmail.com wrote: Hi all !! Any idea or colaboration about this ? Regards. -- Forwarded message -- From: e-friend_partner fca...@gmail.com Date: 2012/9/3 Subject: Question's about install subversion server in a NAS (network attached storage). To: users-i...@subversion.apache.org Hi comunity !! I'm looking for documentation on this case, but I don't find the subject documented. The issue is to install Subversion on a NAS (network attached storage) for access and internal use. In Section 3.5 Accessing the Repository of TortoiseSVN-1.7.8. not recommend installing the repository on a shared network drive, but the NAS does not see it as a simple - network drive. In short, the task is install subversion in a repository type NFS / samba and access it with windows TortoiseSVN client on an internal network. In this doc. svnbook (http://svnbook.red-bean.com/en/1.7/svn.serverconfig.html) mention that can be installed in three schemes: svnserver server, svnserver on ssh and http server apahe., but not clear to me which of these three can serve me for the model that I presented previously. 1. Has anyone installed on the NAS as configured and installed? 2. Whether or not it can install the SVN server on a NAS? 3. Please would yo give me advice about this subject ? -- Regards, Fabio C. -- Saludos, Fabio Celis A.
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: Git smudge / Clean / Filter alike in Subversion ?
On Tue, Sep 11, 2012 at 02:45:49PM +0200, Laurent Alebarde wrote: Thanks for your answer Stefan, Unfortunatly, no : The first link says Subversion is smart with binary files. That's good to hear, but do not provide a filter or filter hook between the workspace and the repository. Apart from built-in properties such as svn:keywords and svn:eol-style, there is no way to make changes to files during checkout or commit. You can probably use a wrapper script for this purpose, however, that wraps svn checkout, svn update, and svn commit. What do you really need this feature for? I'm interested in learning more about your actual use case, the actual problem you're trying to solve, rather than what git's solution to your problem is. Maybe if I knew more about the problem itself I could give you a better answer. And maybe we can add some feature to svn to solve your problem, once we understand the problem. The second link says it can use external diff. But that's not what I want to do. I just want to put a filter in the middle between the files to diff and the internal diff. This is not supported. A workaround might be to use an external diff tool and filter its output instead.
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: Git smudge / Clean / Filter alike in Subversion ?
Le 11/09/2012 15:49, Stefan Sperling a écrit : On Tue, Sep 11, 2012 at 02:45:49PM +0200, Laurent Alebarde wrote: Thanks for your answer Stefan, Unfortunatly, no : The first link says Subversion is smart with binary files. That's good to hear, but do not provide a filter or filter hook between the workspace and the repository. Apart from built-in properties such as svn:keywords and svn:eol-style, there is no way to make changes to files during checkout or commit. You can probably use a wrapper script for this purpose, however, that wraps svn checkout, svn update, and svn commit. What do you really need this feature for? I'm interested in learning more about your actual use case, the actual problem you're trying to solve, rather than what git's solution to your problem is. Maybe if I knew more about the problem itself I could give you a better answer. And maybe we can add some feature to svn to solve your problem, once we understand the problem. Sure, you are right. At present time, my use cases are : 1) Automatic coding style refactoring so that developpers remain happy with what they are used to : indentation, naming, layout, etc. 2) Automatic doxygen comments generation. 3) Add information in the code in the workspace, from tags included in the repository The 2 first use cases need a filter between the workspace and the repository. The 3rd one needs a filter between the workspace and the internal or external diff. Hope the clarification is right. The second link says it can use external diff. But that's not what I want to do. I just want to put a filter in the middle between the files to diff and the internal diff. This is not supported. A workaround might be to use an external diff tool and filter its output instead. No, from my use case 3, this is not a solution.
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: Git smudge / Clean / Filter alike in Subversion ?
On Sep 11, 2012, at 09:48, Laurent Alebarde wrote: Le 11/09/2012 15:49, Stefan Sperling a écrit : What do you really need this feature for? I'm interested in learning more about your actual use case, the actual problem you're trying to solve, rather than what git's solution to your problem is. Maybe if I knew more about the problem itself I could give you a better answer. And maybe we can add some feature to svn to solve your problem, once we understand the problem. Sure, you are right. At present time, my use cases are : 1) Automatic coding style refactoring so that developpers remain happy with what they are used to : indentation, naming, layout, etc. The usual Subversion solution for this is to either a) write a pre-commit hook that verifies that the code conforms to the style guidelines, and rejects the commit if it does not; or b) write a post-commit hook that converts code to the required style and commits this in a second revision 2) Automatic doxygen comments generation. Here too the usual Subversion solution is to have a post-commit hook generate this and then commit it. Another common answer is that things that can be generated should not be stored in the repository. 3) Add information in the code in the workspace, from tags included in the repository I don't understand... could you give an example?
Re: Git smudge / Clean / Filter alike in Subversion ?
On Tue, Sep 11, 2012 at 04:48:12PM +0200, Laurent Alebarde wrote: Le 11/09/2012 15:49, Stefan Sperling a écrit : On Tue, Sep 11, 2012 at 02:45:49PM +0200, Laurent Alebarde wrote: Thanks for your answer Stefan, Unfortunatly, no : The first link says Subversion is smart with binary files. That's good to hear, but do not provide a filter or filter hook between the workspace and the repository. Apart from built-in properties such as svn:keywords and svn:eol-style, there is no way to make changes to files during checkout or commit. You can probably use a wrapper script for this purpose, however, that wraps svn checkout, svn update, and svn commit. What do you really need this feature for? I'm interested in learning more about your actual use case, the actual problem you're trying to solve, rather than what git's solution to your problem is. Maybe if I knew more about the problem itself I could give you a better answer. And maybe we can add some feature to svn to solve your problem, once we understand the problem. Sure, you are right. At present time, my use cases are : 1) Automatic coding style refactoring so that developpers remain happy with what they are used to : indentation, naming, layout, etc. In Subversion you can block commits that do not conform to policy by creating a pre-commit hook that evaluates changes about to be committed, and allows or rejects the commit based on that. This then requires developers to e.g. heed coding style to be able to commit. They could also use tools to modify files in their working copy before committing. I.e. the only difference is that there is no way to plug the fix-up tooling into svn itself, but that people are required to use this tooling in _addition_ to svn, before committing. However, if your pre-commit checks are too strict and there is no way to bypass them, people might end up not committing at all for longer than necessary, which is also bad. You should at least provide a way to bypass these checks (e.g. by putting a special marker into the log message) to allow for unforeseen circumstances where developers need to override these checks. 2) Automatic doxygen comments generation. If this can be done in an automated way, why bother developer working copies with it at all? You could create an automated job that has its own working copy, updates to get new changes, makes any necessary doxygen modifications, and commits the result. svn can be scripted for these kinds of purposes. See the --non-interactive and --xml options that many svn commands support. 3) Add information in the code in the workspace, from tags included in the repository The 2 first use cases need a filter between the workspace and the repository. The 3rd one needs a filter between the workspace and the internal or external diff. I don't think I understand 3), especially what diff has got to do with it. What is this for? Is this information meant for interactive use by developers while developing? Or is it some extended information of the sort that svn:keywords supports, which is embedded in files you ship to customers (outside the version control system)? In the latter case, you might as well use a separate working copy to add this extra information, and commit it from there, instead of forcing unrelated changes into developer working copies. I realise that git can easily hide modifications by automatically making them in the index instead of the working tree. So if you're adding information which developers don't really need to see on they fly while files are being added to the index, this doesn't bother them much. However, Subversion does not have a concept of an index like git does. There is only a working copy and a repository. So you're really talking about making edits to peoples' working files, which may or may not be desirable, depending on the use case. And keep in mind that developers might have their files opened up in editors while they run 'svn update' or 'svn commit', and you would be making changes to the files concurrently. I'd imagine that could lead to unexpected results. My advice would be to use automated jobs that use separate working copies, if at all possible, and leave developer working copies alone. They'll get to see modifications made by automated commits just like any other commits when they run 'svn update'.
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?) then
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
Limiting Subversion noise in apache logs
I've always been slightly annoyed with Apache 401 unauthorized log
entries
when accessing a Subversion repository. I realize these are part of the
standard authentication handshake via the http protocol.
(Always ask anonymously first...)
I also realize that mod_dav_svn can now provide a custom log file, but I
like
my apache logs. On a busy server, these can get to be tens of gigabytes
per
day. I'm not aware of a way to limit log entries based upon return status
codes...
As a test, I think I have been able to abuse the rewrite_module to get rid
of these apache 401 log entries and I was wondering if any
Apache/Subversion
gurus could poke holes in why this either doesn't work or shouldn't be
used:
IfModule rewrite_module
# Do not log authentication required responses
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteCond %{LA-U:REMOTE_USER} =
RewriteCond %{REQUEST_URI} !-U
RewriteRule .* - [Last, ENV=dontlog:1]
/IfModule
IfModule log_config_module
LogFormat %h %l %u %t \%r\ %s %b common
CustomLog logs/access.log common env=!dontlog
/IfModule
I'm aware the sub-request for the last RewriteCond line is expensive. I'm
hopeful the other RewriteCond lines would short circuit most of the server
accesses. Does Subversion create any connections with something
other than an initial OPTIONS request? I only trivially tested neon. I
added
that condition as a hopeful performance improvement.
And yes, as I stated above, I realize Subversion can create it's own
custom log, but using that removes the fun in this experiment...
Kevin R.
