You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2012/09/10 17:32:13 UTC
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
Posted by John Maher <Jo...@rotair.com>.
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:dcchapman@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 dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
Re: general questions
Posted by David Chapman <dc...@acm.org>.
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 dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
>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:lesmikesell@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
lesmikesell@gmail.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
> But exactly for those wrappers there is no point in
> trying to do *everything* the CLI can do in the GUI as well
I disagree. The point is to make the job easier. Having to switch
around would prove the point that it is not helping much. I agree to
streamline what needs to be done. But I also would want to be able to
pass any text to svn that I want. That gives me the best of both
worlds. I get the simplicity of the gui and also get to enter anything
I want, even " status | awk '/I / { print $2 } | xargs rm" by just
typing it in and passing it to svn. Not only does that handle things
that would be unfeasible it keeps things consistent. Perhaps you need
to be a system programmer to understand.
A script is just a subset of a full fledged program. In other words, a
program can do all a script can do and more. I bet other users on this
list are getting a good laugh at this discussion. I know I am!!
Your turn.
John
-----Original Message-----
From: Andreas Krey [mailto:a.krey@gmx.de]
Sent: Tuesday, September 11, 2012 1:36 PM
To: John Maher
Cc: Les Mikesell; David Chapman; Mark Phippard;
users@subversion.apache.org
Subject: Re: general questions
On Tue, 11 Sep 2012 13:11:08 +0000, John Maher wrote:
...
> I don't understand this statement at all. I'm talking about a simple
> wrapper.
Ok, I got that wrong. But exactly for those wrappers there is no point
in
trying to do *everything* the CLI can do in the GUI as well. Streamline
the most important things. I've done such a thingie for myself for cvs;
you could just run update (where in svn you'd do status), click on
filenames to see the diff, and commit. Nothing more needes; the only
point was not to cut&pase the filenames.
Interestingly I do the same with git on the command line because those
tools have gotten better and more streamlined there.
> And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.
You can't especially not shell invocations, as that would viod the
spriti
of the GUI.
> Again, if necessary it can be, very easy. However that is not the
point
> of the wrapper.
Yes, it is. Imagine a GUI for 'svn status'. Now imagine how you'd
do the equivalent of 'svn status | awk '/I / { print $2 } | xargs rm'
with that GUI, or even with the help of that GUI for the svn part.
Putting that in a script and name it svn-clean is two lines.
Putting that in a GUI (and esp. your svn status wrapper) is..how much?
...
> in designing a program. They are not
> as limited as you believe them to be.
Programs aren't. GUIs are, exactly because of their primary goal.
They want to avoid the plugs and bolts at the outside, and thus they
aren't pluggable and boltable. (And yes, they do make many things
easier. And other things impossible.) Even Word has a CLI; even
though it's gruesome and called word basic.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: general questions
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 11 Sep 2012 13:11:08 +0000, John Maher wrote:
...
> I don't understand this statement at all. I'm talking about a simple
> wrapper.
Ok, I got that wrong. But exactly for those wrappers there is no point in
trying to do *everything* the CLI can do in the GUI as well. Streamline
the most important things. I've done such a thingie for myself for cvs;
you could just run update (where in svn you'd do status), click on
filenames to see the diff, and commit. Nothing more needes; the only
point was not to cut&pase the filenames.
Interestingly I do the same with git on the command line because those
tools have gotten better and more streamlined there.
> And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.
You can't especially not shell invocations, as that would viod the spriti
of the GUI.
> Again, if necessary it can be, very easy. However that is not the point
> of the wrapper.
Yes, it is. Imagine a GUI for 'svn status'. Now imagine how you'd
do the equivalent of 'svn status | awk '/I / { print $2 } | xargs rm'
with that GUI, or even with the help of that GUI for the svn part.
Putting that in a script and name it svn-clean is two lines.
Putting that in a GUI (and esp. your svn status wrapper) is..how much?
...
> in designing a program. They are not
> as limited as you believe them to be.
Programs aren't. GUIs are, exactly because of their primary goal.
They want to avoid the plugs and bolts at the outside, and thus they
aren't pluggable and boltable. (And yes, they do make many things
easier. And other things impossible.) Even Word has a CLI; even
though it's gruesome and called word basic.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: general questions
Posted by Johan Corveleyn <jc...@gmail.com>.
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:lesmikesell@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=poFQAAAAMAAJ
> The concepts still save me time every day.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
So you think 100 years from now people will be entering text based
commands? I disagree. And some people still ride horses today for
transportation. Doesn't mean I'm gonna get one. But that's OK, because
of the people needing horses it gives people who know how to groom
horses a job, which is a good thing. Just not for me.
And I don't have a lot of faith in windows retaining its market share.
Enjoy
John
-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Tuesday, September 11, 2012 3:29 PM
To: John Maher
Cc: users@subversion.apache.org
Subject: 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
Posted by Andy Levy <an...@gmail.com>.
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
Posted by Dave Huang <kh...@azeotrope.org>.
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: khym@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
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
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:lesmikesell@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=poFQAAAAMAAJ
The concepts still save me time every day.
--
Les Mikesell
lesmikesell@gmail.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
On Tue, Sep 11, 2012 at 12:11 PM, John Maher <Jo...@rotair.com> wrote:
>> You're confusing a single application with the whole command line
>> and *everything* it can invoke. In your picture that whole set of all
>> commands available now or in the future is the 'the application' for
>> which you'd need to design a GUI, would you want to have its
> flexibility
>> available in a GUI.
>
> I don't understand this statement at all. I'm talking about a simple
> wrapper. And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.
On the command line, every piece of text, including the base command
to run can be the expansion of shell variables, file wildcards, or the
output of any other program. If a GUI offers any of those options
you pretty much lose any point/click advantage it might have since the
choices approach infinity. The input can be the output of any other
program. If the tool doesn't do the complete job, the output can go
to any other tool.
>> Interaction with *other* applications (the trailer) isn't designed in,
>> and can't be automated.
>
> Again, if necessary it can be, very easy. However that is not the point
> of the wrapper. If I want to build a car you can say but it can't fly.
> And it can't float. You're right. It isn't supposed to. You can
> always pick fault about something if you go beyond its scope.
That's the point here. Things based on text stream processing don't
have 'scopes' or associated limits. Likewise for command lines based
on text expansions.
>> GUI applications are designed to interact with a user, and not with
>> other applications
>
> Again that is not true. Well the first part is. The second part (("not
> with other applications") may or may not be true. Depends on the app.
> I'm starting to learn who isn't a programmer because they have common
> misconceptions about how programs are designed. I wonder if its from
> watching TV?
Starting here worked out pretty well for me:
http://books.google.com/books/about/The_UNIX_programming_environment.html?id=poFQAAAAMAAJ
The concepts still save me time every day.
--
Les Mikesell
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
> 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.krey@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 +0000, John Maher wrote:
...
> line can except take more time to do something. You're confusing the
> steps to design an application with the steps to design a wrapper.
You're confusing a single application with the whole command line
and *everything* it can invoke. In your picture that whole set of all
commands available now or in the future is the 'the application' for
which you'd need to design a GUI, would you want to have its flexibility
available in a GUI.
> different animals and if you mix the two its like trying to pull a
> trailer with a corvette. It may work, it may cause problems. It
> definitely is not optimal.
That's because a corvette isn't designed for a trailer hook. That
is exactly the situation with all kinds of GUis: Interaction
with *other* applications (the trailer) isn't designed in,
and can't be automated.
GUI applications are designed to interact with a user, and not with
other applications, and that is their general deficiency for some
kinds of work.
Try to get you browser and photoshop to play together and download,
scale, and publish a webcam pic every hour, and you see the non-power
of the GUI.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: general questions
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 11 Sep 2012 12:02:51 +0000, John Maher wrote:
...
> line can except take more time to do something. You're confusing the
> steps to design an application with the steps to design a wrapper.
You're confusing a single application with the whole command line
and *everything* it can invoke. In your picture that whole set of all
commands available now or in the future is the 'the application' for
which you'd need to design a GUI, would you want to have its flexibility
available in a GUI.
> different animals and if you mix the two its like trying to pull a
> trailer with a corvette. It may work, it may cause problems. It
> definitely is not optimal.
That's because a corvette isn't designed for a trailer hook. That
is exactly the situation with all kinds of GUis: Interaction
with *other* applications (the trailer) isn't designed in,
and can't be automated.
GUI applications are designed to interact with a user, and not with
other applications, and that is their general deficiency for some
kinds of work.
Try to get you browser and photoshop to play together and download,
scale, and publish a webcam pic every hour, and you see the non-power
of the GUI.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
> What they don't do is let me build on things that already work in
> arbitrary ways (especially in other languages and on other
> machines...), and add to that when I have anything else that works.
> Maybe they could, but then they would become a programming language
> themselves.
Actually, they can Les and would not become a programming language
themselves, that's what states and return codes are for. And you can
call programs from other programs, but that's beyond the scope of the
task. Actually you're blowing this all out of proportion. I'm talking
about a simple wrapper to streamline actions normally required by
issuing commands. You're thinking of my tool for your job, it won't
work. It won't even work for my job, it will not write code. My tool
will work for part of my job, just like the issued commands that it
would replace.
> That's fine if you want to buy a new vehicle for everything you
> transport,
Again, you miss the point. You don't but a new vehicle for everything
you wish to transport. You buy 1 truck to do the transporting. It has
noting to do with re-using. In fact, programming is all about reusing.
I would be reusing lots of stuff. You can re-use everything either way.
I can call grep or anything else, it is irrelevant. It is simply a
different way to input something. That's it. Nothing more. Any extra
stuff you pile on top will only confuse you. You don't have to like
guis or programmers. But to say they are not useful or detrimental is a
prejudice that can hurt you because it frankly is not a fact.
-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com]
Sent: Tuesday, September 11, 2012 12:30 PM
To: John Maher
Cc: David Chapman; Mark Phippard; users@subversion.apache.org
Subject: 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
lesmikesell@gmail.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
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:lesmikesell@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
combining all of the functionality of existing commands with script
wrappers and a few of my own is going to win.
> Although you can never
> predict a user 100% of the time, you can learn to be spot on 50% (or
> better) of the time. And you seem to be forgetting a gui can do
> anything text can do by offering a textbox.
No, a textbox is not the same at all. Text tools allow running any
program you want to expand the result. I suppose a textbox 'could'
let you put in $(cat wild_card_filename) or $(grep pattern filename)
and accept the result like any bash command line will, but I've never
seen a GUI do that.
> There's a bazillion right
> there.
But that's a bazillion you have to input There's an old saying that
GUI's make 'easy things easier and difficult things impossible'.
> You also have a bazillion at the command line.
Which can be generated by any other tool at my disposal.
> I think what you
> are picturing is nothing like what I am planning. lol. At least I
> would never use the same words to describe it as you do.
OK, but I spent a couple of days 20+ years ago learning how to combine
the work of different tools with simple shell scripting and it has
saved me time pretty much every day since. But, I tend to think that
the best user interface is no interface at all - that is, the machines
should just do your work for you in the cases where it is predictable,
and it should be trivial to repeat complex sequences even when you
have to do it manually. If you have to do some set of operations
across 44 instances of something today, how will your GUI help you
automate that set of operations on the next 44? If you did it on the
command line, you'd just recall the command and edit the target. Or
save it in a file that you can edit easily, or come up with a way
another tool can generate the target list. The 'graphic display' of
the operation isn't particularly useful on its own here - you just
want the underlying work done.
--
Les Mikesell
lesmikesell@gmail.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
On Tue, Sep 11, 2012 at 7:22 AM, John Maher <Jo...@rotair.com> wrote:
> Interesting discussion. It appears you have not had the chance to work
> with a good wrapper, or maybe you shun guis or something because there
> appears to be a strong bias to your statements.
First, let me remind you that you started the discussion, complaining
about not being able to find the way to do what you wanted in a GUI.
> I have been a
> programmer AND user on both sides, gui and command line, so I am not
> making things up.
I'm more of a system administrator, so used to doing things that
aren't designed into GUIs as everyday operations for most users.
>> I'm not saying GUIs don't work. Just that they are generally a subset
>> of what can be done with commands.
>
> This is simply not true. Expose every function and every parameter and
> there is nothing the gui can not do. Add some automation, and the gui
> can actually do more.
But that's within a single application. Well designed command line
tools and scripting languages include all of each others'
functionality fairly seamlessly. While a GUI 'could' let me run a
program of my choice to supply any option or input, none that I've
seen actually do. So they are limited to what the designer
anticipated where the command line tools gain functionality as new
tools are developed or you add your own helper/wrapper scripts.
>> You are making some assumptions about scale and locality here. I have
>> most of the world at my fingertips in the form of URLs.
>
> Of course I am. I must make some assumptions or there is nothing to
> talk about. Don't forget a gui can have a box where a URL is entered so
> it can do everything you can by just typing in stuff plus anything else
> that gets added.
But, I said I would have a list of URLs in a file. Your GUI 'could'
let me provide the file as input. But that would be a rare choice for
a GUI designer and a common scenario for me. So if forced to use a
gui for a repeated operation, I'd probably end up displaying the file
in one window and cutting/pasting a line at a time as I repeat the
many mouse-clicks it might take for the rest of the work.
>> OK, but if I regularly work with 44 repositories, I'm likely to have
>> their URLs in a file where a script can extract them a lot faster than
>> you can navigate the world in a picklist.
>
> Now you're making assumptions, that's OK though. Makes for a good
> discussion. And you are right. Nothing works best 100% of the time.
> Now think of the reverse of that. What if you wish to do something to
> 44 repositories once? Whats better typing them all in or clicking on
> them. You can type, I'll click.
My assumptions are from past history. Picking 44 names out of 100
might be a win. Picking 44 out of 50,000, I'd rather just type them
in, but if I am creating a new, arbitrary set of names for related
things I'd use a name convention where wildcards or number sequences
make the set script-friendly for operations on the group. If someone
else has given me the names, we are back to already having the list in
a file and the script just has to iterate over it.
>> But it can only be a good design after you already now what I'm going
>> to do. Until then you can only offer the bazillion choices.
>
> Again, not true. With experience comes wisdom.
How does that differ from what I said? If the GUI designer knows
what I'm going to do and wants to spend the time making it easier,
then yes, the GUI approach can be nicer. But if I want to do
something new and different (and what's the point if I don't?) then
combining all of the functionality of existing commands with script
wrappers and a few of my own is going to win.
> Although you can never
> predict a user 100% of the time, you can learn to be spot on 50% (or
> better) of the time. And you seem to be forgetting a gui can do
> anything text can do by offering a textbox.
No, a textbox is not the same at all. Text tools allow running any
program you want to expand the result. I suppose a textbox 'could'
let you put in $(cat wild_card_filename) or $(grep pattern filename)
and accept the result like any bash command line will, but I've never
seen a GUI do that.
> There's a bazillion right
> there.
But that's a bazillion you have to input There's an old saying that
GUI's make 'easy things easier and difficult things impossible'.
> You also have a bazillion at the command line.
Which can be generated by any other tool at my disposal.
> I think what you
> are picturing is nothing like what I am planning. lol. At least I
> would never use the same words to describe it as you do.
OK, but I spent a couple of days 20+ years ago learning how to combine
the work of different tools with simple shell scripting and it has
saved me time pretty much every day since. But, I tend to think that
the best user interface is no interface at all - that is, the machines
should just do your work for you in the cases where it is predictable,
and it should be trivial to repeat complex sequences even when you
have to do it manually. If you have to do some set of operations
across 44 instances of something today, how will your GUI help you
automate that set of operations on the next 44? If you did it on the
command line, you'd just recall the command and edit the target. Or
save it in a file that you can edit easily, or come up with a way
another tool can generate the target list. The 'graphic display' of
the operation isn't particularly useful on its own here - you just
want the underlying work done.
--
Les Mikesell
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
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:lesmikesell@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
lesmikesell@gmail.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
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:lesmikesell@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
lesmikesell@gmail.com
Re: general questions
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
RE: general questions
Posted by Bob Archer <Bo...@amsi.com>.
> 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
Posted by Mark Phippard <ma...@gmail.com>.
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
Posted by John Maher <Jo...@rotair.com>.
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:markphip@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
Posted by Mark Phippard <ma...@gmail.com>.
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
Posted by John Maher <Jo...@rotair.com>.
Thanks Bob. Exactly what I was looking for.
John
-----Original Message-----
From: Bob Archer [mailto:Bob.Archer@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
Posted by Bob Archer <Bo...@amsi.com>.
> > 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
Posted by John Maher <Jo...@rotair.com>.
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.Archer@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
Posted by John Maher <Jo...@rotair.com>.
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:tschoening@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.Schoening@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
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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
Posted by John Maher <Jo...@rotair.com>.
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:dcchapman@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 dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
Re: general questions
Posted by David Chapman <dc...@acm.org>.
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 dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
RE: general questions
Posted by John Maher <Jo...@rotair.com>.
Thank you very much. Now I can get back to reading.
John
________________________________
From: Mark Phippard [mailto:markphip@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
Posted by Mark Phippard <ma...@gmail.com>.
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
Posted by John Maher <Jo...@rotair.com>.
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:markphip@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 in
the summer. It talks about creating a repository, then goes on about
properties. I am trying to follow it but then have to change chapters
because creating repositories is discussed in other places AFTER you
need them to exist to test out properties.
The book is open source so feel free to suggest and contribute ideas for
improvements. It is obviously difficult to strike the right balance for
giving a high level explanation of the tool and how it works, as well as
comprehensive reference documentation AND cookbook like how-to. I think
it does a great job with the high-level, is fairly good for reference
material and only lightly wades into the cookbook area with some of the
examples. That said, there is a ton of the cookbook type information in
blogs and articles on the web now so it is not hard to find it.
I did find the hooks directory on the server, the VisualSVN
server just doesn't show them.
I believe they have a free and commercial version so maybe they only
have this in the UI for the commercial version? It ought to be possible
to edit the files in the hooks folder and have them work either way.
Subversion Edge is free (and open source) and provides it via web UI.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: general questions
Posted by Mark Phippard <ma...@gmail.com>.
Please keep replies on the mailing list.
On Mon, Sep 10, 2012 at 12:02 PM, John Maher <Jo...@rotair.com> wrote:
> Thanks again Mark, you have been helpful. Let me clear some things up.**
> **
>
> ** **
>
> Let me clear up by what I mean as “local” repository. We have a svn
> server which has repositories on it. It serves us files to our local
> directories when we ask for them using VisualSVN Server. I also created
> some repositories “locally” with svnadmin create. The repositories are on
> the same machine, on the same drive as the working copy and I can get a
> working copy without any network access and do not need VisualSVN Server,
> Subversion Edge or any other server to create or access it. Sure you can
> say the server is MyMachineName and the client is MyMachineName. However
> the repositories ARE different because svnadmin works with one type and
> fails with another. Perhaps you never used the second type. If you have
> what would you call it to differentiate between them?
>
They are just repositories. You can say you are accessing one via file://
protocol and one via http:// protocol if you like.
svnadmin only operates directly on the file system via the OS. It does not
talk to anything except the bytes on disk. So it needs access to those
bytes. The normal thing to do is to run svnadmin on the server where you
want your repositories to live. You login to the server directly using
something like an SSH terminal or a Remote Desktop.
When you run a GUI on your server like VisualSVN or SVN Edge, those tools
are simply providing a way to run the svnadmin command via some other
remote access interface such as your web browser.
> I am still wondering about the issue I read somewhere it said you should
> use a what-ever-you-want-to-call-it repository via a URL and a server
> product (like VisualSVN Server) instead of a what-ever-you-want-to-call-it
> repository on a network drive without using a server product (using
> svnadmin create) in a multi-user environment.
>
You can create repositories on a network share and access them via file://
protocol but you shouldn't. All users need full read/write access to the
repository files if you do this, which means they can accidentally delete
or corrupt those files. Of course they can also do so for
malicious/intentional reasons. Accessing the repository this way will also
typically be significantly slower than accessing them via a server.
And we have numerous files we need to ignore. We are using visual studio.
> We have a project which consists of 44 dlls. Each dll is in its own
> directory and is a project in and of itself. Each directory contains files
> and directories which need to be ignored when a new user creates a working
> copy so the user’s settings don’t get stepped on. So that means entering
> the svn:ignore command 44 times at least for this one project alone. I was
> hoping for a better way.
>
You can setup clients to ignore the DLL extensions always, but that has to
be done on each client. Setting svn:ignore is the better way and it only
has to be done by one user and then committed to the repository for all
others.
> We do have TortiseSVN. The documentation is quite poor with this product.
>
Well, I disagree. At least compared to every other SVN client, they have
the best and most complete documentation. I cannot speak to the commercial
clients, maybe some of them are better but I doubt it.
That is the reason I am reading the book, which is NOT an easy read by
> the way, unless of course you already know the subject.
>
I think it is an easy read. That is how I learned Subversion. I was
coming from an AS/400 background where version control is quite different.
I had used PVCS and SourceSafe quite a bit, and CVS a little bit. From
reading the book when Subversion 1.0 came out, I felt like I understood the
tool almost immediately. Obviously there was still a lot more I learned
over the years by experience and this mailing list, but the book laid the
ground work. Understanding things like repositories, working copies,
revisions and mixed revision working copies are all essential concepts and
I think the book explains them well.
The book jumps around worse than a bullfrog on a blacktop in the summer.
> It talks about creating a repository, then goes on about properties. I am
> trying to follow it but then have to change chapters because creating
> repositories is discussed in other places AFTER you need them to exist to
> test out properties.
>
The book is open source so feel free to suggest and contribute ideas for
improvements. It is obviously difficult to strike the right balance for
giving a high level explanation of the tool and how it works, as well as
comprehensive reference documentation AND cookbook like how-to. I think it
does a great job with the high-level, is fairly good for reference material
and only lightly wades into the cookbook area with some of the examples.
That said, there is a ton of the cookbook type information in blogs and
articles on the web now so it is not hard to find it.
> I did find the hooks directory on the server, the VisualSVN server just
> doesn’t show them.
>
I believe they have a free and commercial version so maybe they only have
this in the UI for the commercial version? It ought to be possible to edit
the files in the hooks folder and have them work either way. Subversion
Edge is free (and open source) and provides it via web UI.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/