Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2659 > unrolled thread

programmer's keyboard

Back to article view | Back to comp.programming

Contents

  programmer's keyboard bob <bob@coolfone.comze.com> - 2012-12-26 11:45 -0800
    Re: programmer's keyboard Robert Wessel <robertwessel2@yahoo.com> - 2012-12-26 15:01 -0600
      Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-26 21:36 +0000
        Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-26 21:12 -0600
        Re: programmer's keyboard Robert Wessel <robertwessel2@yahoo.com> - 2012-12-27 23:45 -0600
          Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-28 13:46 +0000
            Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-29 11:42 +1300
            Re: programmer's keyboard "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-29 15:15 +0000
              Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-29 14:41 -0600
                Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-29 21:10 +0000
                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-29 15:26 -0600
                    Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-29 22:41 +0000
                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 02:12 -0600
                        Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-30 11:20 +0000
                          Re: programmer's keyboard malcolm.mclean5@btinternet.com - 2012-12-30 10:19 -0800
                            Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 14:51 -0600
                Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-30 10:43 +1300
                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 01:55 -0600
                    Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-30 21:06 +1300
                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 02:35 -0600
                        Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2012-12-30 18:12 +0000
                          Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 13:30 -0600
                            Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-31 09:36 +1300
                              Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 17:27 -0600
                                Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-31 13:00 +1300
                                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-31 03:13 -0600
                                    version control (was: Re: programmer's keyboard) rugxulo@gmail.com - 2012-12-31 10:36 -0800
                                    Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2013-01-01 09:05 +1300
                                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-31 16:58 -0600
                                        Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2013-01-01 13:24 +1300
                                    Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-02 12:23 +0000
                                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-02 14:34 -0600
                                        Re: programmer's keyboard Robert Wessel <robertwessel2@yahoo.com> - 2013-01-02 15:35 -0600
                                          Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-03 13:19 -0600
                                        Re: programmer's keyboard Willem <willem@turtle.stack.nl> - 2013-01-03 08:35 +0000
                                          Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-03 13:46 -0600
                                        Re: programmer's keyboard rugxulo@gmail.com - 2013-01-03 00:52 -0800
                                        Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-03 15:00 +0000
                                Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-02 11:58 +0000
                                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-02 15:03 -0600
                                    Re: programmer's keyboard rugxulo@gmail.com - 2013-01-03 00:54 -0800
                                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-03 13:06 -0600
                    Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2012-12-30 18:04 +0000
                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 14:24 -0600
                        Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-02 11:34 +0000
            Writing Experimental Code "Aaron W. Hsu" <arcfide@sacrideo.us> - 2013-01-02 15:08 -0600
    Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2012-12-28 11:45 +0000
      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-28 12:29 -0600

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#2696

BGB wrote:

> last time I tried to use mercurial (and bitbucket), basically via the
> Windows Explorer plugin thinggy, it took absurdly long for it to try to
> synchronize or commit changes. for a roughly 5GB project, it would
> seemingly do single massive uploads/downloads (several GB at a time),
> and take a long time, and often fail.
> 
> with just myself working on it, it didn't really seem worthwhile.

5GB sounds like an awful lot of data, particularly if you need to store it 
in a server somewhere.  Some ISPs offer monthly data plans whose monthly 
traffic is only a fraction of that.


> with a local copy/paste, I can do the whole operation of copying
> source-trees around much quicker, even yes, if file-copying is still
> kind of slow sometimes...
> 
> and, if a person needs a copy on an external drive, they can copy/paste
> it to an external drive, and call it good enough...

You can use version control systems to manage local projects, without having 
to transfer any data through a network.  You can also copy the whole project 
around, versioned data and all.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2698

On 12/30/2012 12:12 PM, Rui Maciel wrote:
> BGB wrote:
>
>> last time I tried to use mercurial (and bitbucket), basically via the
>> Windows Explorer plugin thinggy, it took absurdly long for it to try to
>> synchronize or commit changes. for a roughly 5GB project, it would
>> seemingly do single massive uploads/downloads (several GB at a time),
>> and take a long time, and often fail.
>>
>> with just myself working on it, it didn't really seem worthwhile.
>
> 5GB sounds like an awful lot of data, particularly if you need to store it
> in a server somewhere.  Some ISPs offer monthly data plans whose monthly
> traffic is only a fraction of that.
>

yeah. partly it is a game project, and there are a lot of data files.
there is a "mini" version of the project that can be downloaded, but it 
mostly works by using a stripped down version of the data (which omits a 
lot of development data, uses low-resolution textures, ...).


>
>> with a local copy/paste, I can do the whole operation of copying
>> source-trees around much quicker, even yes, if file-copying is still
>> kind of slow sometimes...
>>
>> and, if a person needs a copy on an external drive, they can copy/paste
>> it to an external drive, and call it good enough...
>
> You can use version control systems to manage local projects, without having
> to transfer any data through a network.  You can also copy the whole project
> around, versioned data and all.
>

granted, but it isn't really all that clear if/how it is worth the 
hassle of doing so.

[toc] | [prev] | [next] | [standalone]

#2700

BGB wrote:
> On 12/30/2012 12:12 PM, Rui Maciel wrote:
>>
>> You can use version control systems to manage local projects, without having
>> to transfer any data through a network.  You can also copy the whole project
>> around, versioned data and all.
>>
>
> granted, but it isn't really all that clear if/how it is worth the
> hassle of doing so.

The "hassle" of typing "hg commit" once in a while is far outweighed by 
the convenience of being able to type "hg revert" when you break something.

As for copying, with Mercurial at least, everything in in the source 
directory, so there's no additional effort required.  Because you don't 
have all those dated directories floating around, where's way less data 
to copy.

The convenience of being able to use ssh to clone and synchronise 
between hosts and devices is a big win.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2702

On 12/30/2012 2:36 PM, Ian Collins wrote:
> BGB wrote:
>> On 12/30/2012 12:12 PM, Rui Maciel wrote:
>>>
>>> You can use version control systems to manage local projects, without
>>> having
>>> to transfer any data through a network.  You can also copy the whole
>>> project
>>> around, versioned data and all.
>>>
>>
>> granted, but it isn't really all that clear if/how it is worth the
>> hassle of doing so.
>
> The "hassle" of typing "hg commit" once in a while is far outweighed by
> the convenience of being able to type "hg revert" when you break something.
>

or, a person can be systematic, and manually revert the last changes 
they made (this being a big win for "#if 0" and "#if 1")

or, maybe just hit CTRL-Z a few times (if the breaking change was recent).

if by some chance they really screw up, copy/paste files from an older 
version.


> As for copying, with Mercurial at least, everything in in the source
> directory, so there's no additional effort required.  Because you don't
> have all those dated directories floating around, where's way less data
> to copy.
>
> The convenience of being able to use ssh to clone and synchronise
> between hosts and devices is a big win.
>

you can also transfer things using, say, FTP, or network shares (if on a 
LAN). (granted, yes, a person needs an FTP server for the FTP route).

an advantage of FTP is that (at least via Windows Explorer) it also 
supports copy/paste and drag-and-drop (of both files and folders).


meanwhile, SSH is only really useful if the other end is running Linux, 
and requires using tools like PuTTY or similar (or, at least, the 
version included with my current install of Cygwin just says "openssl 
failed to initialize").

as-is though, both my main computer and web-server are running Windows...

[toc] | [prev] | [next] | [standalone]

#2703

BGB wrote:
> On 12/30/2012 2:36 PM, Ian Collins wrote:
>> BGB wrote:
>>> On 12/30/2012 12:12 PM, Rui Maciel wrote:
>>>>
>>>> You can use version control systems to manage local projects, without
>>>> having
>>>> to transfer any data through a network.  You can also copy the whole
>>>> project
>>>> around, versioned data and all.
>>>>
>>>
>>> granted, but it isn't really all that clear if/how it is worth the
>>> hassle of doing so.
>>
>> The "hassle" of typing "hg commit" once in a while is far outweighed by
>> the convenience of being able to type "hg revert" when you break something.
>>
>
> or, a person can be systematic, and manually revert the last changes
> they made (this being a big win for "#if 0" and "#if 1")
>
> or, maybe just hit CTRL-Z a few times (if the breaking change was recent).
>
> if by some chance they really screw up, copy/paste files from an older
> version.

So that's all less hassle than "hg revert"?

>> As for copying, with Mercurial at least, everything in in the source
>> directory, so there's no additional effort required.  Because you don't
>> have all those dated directories floating around, where's way less data
>> to copy.
>>
>> The convenience of being able to use ssh to clone and synchronise
>> between hosts and devices is a big win.
>>
>
> you can also transfer things using, say, FTP, or network shares (if on a
> LAN). (granted, yes, a person needs an FTP server for the FTP route).

Share maybe, but handle merging?  Branches?

> an advantage of FTP is that (at least via Windows Explorer) it also
> supports copy/paste and drag-and-drop (of both files and folders).

There's a whole big world outside the windows.

> meanwhile, SSH is only really useful if the other end is running Linux,

Nonsense, ssh is useful out of the box in most decent operating systems 
and probably windows too with the appropriate package.

> and requires using tools like PuTTY or similar (or, at least, the
> version included with my current install of Cygwin just says "openssl
> failed to initialize").
>
> as-is though, both my main computer and web-server are running Windows...

So share your repository via http(s)!

You can use Tortoise HG to pull from or push to remote repositories on 
windows.  You should try it (or Tortoise SVN) some time, it is an 
excellent application.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2704

On 12/30/2012 6:00 PM, Ian Collins wrote:
> BGB wrote:
>> On 12/30/2012 2:36 PM, Ian Collins wrote:
>>> BGB wrote:
>>>> On 12/30/2012 12:12 PM, Rui Maciel wrote:
>>>>>
>>>>> You can use version control systems to manage local projects, without
>>>>> having
>>>>> to transfer any data through a network.  You can also copy the whole
>>>>> project
>>>>> around, versioned data and all.
>>>>>
>>>>
>>>> granted, but it isn't really all that clear if/how it is worth the
>>>> hassle of doing so.
>>>
>>> The "hassle" of typing "hg commit" once in a while is far outweighed by
>>> the convenience of being able to type "hg revert" when you break
>>> something.
>>>
>>
>> or, a person can be systematic, and manually revert the last changes
>> they made (this being a big win for "#if 0" and "#if 1")
>>
>> or, maybe just hit CTRL-Z a few times (if the breaking change was
>> recent).
>>
>> if by some chance they really screw up, copy/paste files from an older
>> version.
>
> So that's all less hassle than "hg revert"?
>

partly yes, because usually this can be done via the GUI, whereas typing 
in "hg revert" could very well involve bringing up a shell, changing to 
the right path, and typing it in.

granted, TorgoiseHg adds revert to Explorer, making the above a bit moot.


the rest would come down mostly to granularity.
(like, if you revert, it will go back to the last commit, meaning being 
strategic about when to commit, ...).

guards, however, can be finer-grained, and can be enabled/disabled at 
will, rather than depending specifically on the immediate history.

and, CTRL-Z is about specific edits, meaning it can undo very recent 
changes, and go as far back (usually) as there are undo levels, or when 
the editor was last closed and reopened (whichever was more recent).



it is much like the tradeoff between using Find/Replace and grep or sed.

Find/Replace is often easier, because it it right there in the editor.

grep and sed are much more powerful, but require using a shell (often a 
different shell from the one used for recompiling), so are usually only 
really justified if one needs to search for something where they really 
can't remember where it is, or where doing a *lot* of replacement, like 
to justify to themselves the effort of opening a new shell and typing 
the relevant 'cd' commands and similar.


this balance gets skewed further if one is dealing with a plain Visual 
Studio project.

granted, yes, in this case, I typically build via the command-line, 
mostly because VS doesn't really scale all that gracefully IMO, and past 
a certain point command-line builds, and managing most of the rest of 
the project via Windows Explorer, become preferable.

granted, VS is pretty useful for small apps and tools though.
granted, yes, a person can also debate the whole MSBuild vs Make thing, 
where I am personally on the Make side.

now, why do I defend using the command-line for this?... because I can 
repeat prior commands with arrow keys and enter. so, past an initial bit 
of typing, the effort-involved is not considerably higher than hitting 
F5 in VS, but there is less annoyance from dealing with VS's lackluster 
file-management and laggy editor (though, I still often use VS for the 
debugger).

granted, yes, a person still has to wait for the compiler to do its 
thing, ...


the convenience balance may be partly reversed on Linux though, mostly 
because on Linux a person will typically have to resort to 'cp' or 
similar, and because the graphical file manager kind-of sucks pretty 
bad... (well, it is like, in GNOME 2, the file manager is bad, and in 
GNOME 3, everything is bad...).


>>> As for copying, with Mercurial at least, everything in in the source
>>> directory, so there's no additional effort required.  Because you don't
>>> have all those dated directories floating around, where's way less data
>>> to copy.
>>>
>>> The convenience of being able to use ssh to clone and synchronise
>>> between hosts and devices is a big win.
>>>
>>
>> you can also transfer things using, say, FTP, or network shares (if on a
>> LAN). (granted, yes, a person needs an FTP server for the FTP route).
>
> Share maybe, but handle merging?  Branches?
>

not usually a big issue for a single developer project.

more so, if the developer does the bulk of their development from a 
single computer (which then generally holds the "authoritative" copy).

more often, if I am going to be away, and have a laptop, I will usually 
make a copy on an external HDD (or "USB Mass Storage Device"), then if I 
work on it more, that version will become the authoritative copy, at 
least until I copy it back onto my main computer.


>> an advantage of FTP is that (at least via Windows Explorer) it also
>> supports copy/paste and drag-and-drop (of both files and folders).
>
> There's a whole big world outside the windows.
>

yes, but this doesn't really matter, if the person is running Windows.


>> meanwhile, SSH is only really useful if the other end is running Linux,
>
> Nonsense, ssh is useful out of the box in most decent operating systems
> and probably windows too with the appropriate package.
>

you can't really effectively administer (normal) Windows though via SSH, 
so its usefulness is greatly reduced vs Linux. partly this is because 
there is actually a lot less that can be done via the command-line on 
Windows, given how much the OS's UI was designed around the GUI.

granted, yes, in the case of a Linux host, there is X over SSH fun, 
making SSH much more useful for a Linux host.


so, remote administration of Windows more generally involves using 
things like VNC or Remote Desktop or similar, which provide full GUI.


>> and requires using tools like PuTTY or similar (or, at least, the
>> version included with my current install of Cygwin just says "openssl
>> failed to initialize").
>>
>> as-is though, both my main computer and web-server are running Windows...
>
> So share your repository via http(s)!
>
> You can use Tortoise HG to pull from or push to remote repositories on
> windows.  You should try it (or Tortoise SVN) some time, it is an
> excellent application.
>

I was using TortoiseHg before with BitBucket.

as noted before, the main killer was the long upload times, and because 
it seemed to want nit-picky things, like creating a new version entry 
and typing something in the changelog, before it would commit anything.


granted, yes, it could be about learning curve or settings or something, 
but in this case, it doesn't make a good case for it being less of a hassle.


less effort depends a lot on situation, like for multiple developers, it 
is probably a lot less effort to use version-control, than deal with the 
hassle that is emailing around code and/or dealing with diff patches.

for a single developer though, it is harder pressed that it is less 
effort, since a lone developer hardly ever has reason to diff their own 
code.

[toc] | [prev] | [next] | [standalone]

#2705 — version control (was: Re: programmer's keyboard)

Hi,

On Monday, December 31, 2012 3:13:02 AM UTC-6, BGB wrote:
> On 12/30/2012 6:00 PM, Ian Collins wrote:
> 
> > BGB wrote:
> >> On 12/30/2012 2:36 PM, Ian Collins wrote:
> >>> BGB wrote:
> >>>> On 12/30/2012 12:12 PM, Rui Maciel wrote:
> >>>>>
> >>>>> You can use version control systems to manage local projects, without
> >>>>> having to transfer any data through a network.  You can also copy
> >>>>> the whole project around, versioned data and all.
> 
> >>>> granted, but it isn't really all that clear if/how it is worth the
> >>>> hassle of doing so.
 
It depends on how much you want to backup and where. If you had multiple projects (and each had different versions), it's presumably easier to "check out" on various machines from network than manually copying and installing via jump drive.
 
> >>> The "hassle" of typing "hg commit" once in a while is far outweighed by
> >>> the convenience of being able to type "hg revert" when you break
> >>> something.
> >>
> >> or, a person can be systematic, and manually revert the last changes
> >> they made (this being a big win for "#if 0" and "#if 1")
 
Yes, but you may not want all that extra fluff in your sources. It might be harder to read that way.
 
> >> if by some chance they really screw up, copy/paste files from an older
> >> version.
> 
> > So that's all less hassle than "hg revert"?
> 
> partly yes, because usually this can be done via the GUI, whereas typing 
> in "hg revert" could very well involve bringing up a shell, changing to 
> the right path, and typing it in.

Make a shortcut that opens the prompt, changes the directory, etc. That's what I do (Ctrl-Alt-D for CMD, Ctrl-Alt-C for Cygwin, Ctrl-Alt-Shift-D for DOSBox).

Actually, a lot of editors support version control plugins already.

> the rest would come down mostly to granularity.
> 
> (like, if you revert, it will go back to the last commit, meaning being 
> 
> strategic about when to commit, ...).
 
Nah, just commit everything that isn't just a temporary (throwaway) hack. Make separate branches for questionable changes.
 
> guards, however, can be finer-grained, and can be enabled/disabled at 
> 
> will, rather than depending specifically on the immediate history.

True, but it might be easier to isolate them in their own separate files and version control those in case you want more than one of them too!
 
> it is much like the tradeoff between using Find/Replace and grep or sed.
> Find/Replace is often easier, because it it right there in the editor.
> grep and sed are much more powerful, but require using a shell (often a 
> different shell from the one used for recompiling), so are usually only 
> really justified if one needs to search for something where they really 
> can't remember where it is, or where doing a *lot* of replacement, like 
> to justify to themselves the effort of opening a new shell and typing 
> the relevant 'cd' commands and similar.

A lot of editors integrate regex replace (even across files), shell handling, file management, command completion and history, etc.

This also reminds me of the following tools:  cscope, global, ctags, cflow, cxref.

> this balance gets skewed further if one is dealing with a plain Visual 
> Studio project.
> granted, yes, in this case, I typically build via the command-line, 
> mostly because VS doesn't really scale all that gracefully IMO, and past 
> a certain point command-line builds, and managing most of the rest of 
> the project via Windows Explorer, become preferable.
> 
> granted, VS is pretty useful for small apps and tools though.
> 
> granted, yes, a person can also debate the whole MSBuild vs Make thing, 
> where I am personally on the Make side.

CMake can output both VCproj and GNU Makefiles, IIRC.

> now, why do I defend using the command-line for this?... because I can 
> repeat prior commands with arrow keys and enter. so, past an initial bit 
> of typing, the effort-involved is not considerably higher than hitting 
> F5 in VS, but there is less annoyance from dealing with VS's lackluster 
> file-management and laggy editor (though, I still often use VS for the 
> debugger).

You don't need a separate shell window just for that, many editors come with support for that. 
 
> the convenience balance may be partly reversed on Linux though, mostly 
> because on Linux a person will typically have to resort to 'cp' or 
> similar, and because the graphical file manager kind-of sucks pretty 
> bad... (well, it is like, in GNOME 2, the file manager is bad, and in 
> GNOME 3, everything is bad...).

You can use a console file manager, e.g. Necromancer's DOS Navigator [sic], YTree, Midnite Commander (mc), etc. if your editor doesn't already support a similar feature.
 
> > Share maybe, but handle merging?  Branches?
> 
> not usually a big issue for a single developer project.
 
If all you want is offline version handling, try RCS. Even CVS can do offline, I think. But most people prefer SVN, Hg, Git (esp. over network).
 
> more so, if the developer does the bulk of their development from a 
> single computer (which then generally holds the "authoritative" copy).

Always have a backup! If not on "teh cloud" (network), at least on a different computer. But I'm with you (sorta), it does seem easier to not fool with version control sometimes. Manual copying is very kludgy, though.

> more often, if I am going to be away, and have a laptop, I will usually 
> make a copy on an external HDD (or "USB Mass Storage Device"), then if I 
> work on it more, that version will become the authoritative copy, at 
> least until I copy it back onto my main computer.

Well, don't "check in" until it works! Test units, etc.  ;-)

> >> an advantage of FTP is that (at least via Windows Explorer) it also
> >> supports copy/paste and drag-and-drop (of both files and folders).

NDN supports all of that.
 
> >> meanwhile, SSH is only really useful if the other end is running Linux,
> 
> > Nonsense, ssh is useful out of the box in most decent operating systems
> > and probably windows too with the appropriate package.

I assume it works fine on Cygwin, but I haven't tried lately.
 
> you can't really effectively administer (normal) Windows though via SSH, 
> so its usefulness is greatly reduced vs Linux. partly this is because 
> there is actually a lot less that can be done via the command-line on 
> Windows, given how much the OS's UI was designed around the GUI.

That's true, but they've added a lot in recent versions (though I'm not sure that I like the idea of PowerShell). I think to them, the console ("true" text mode) is obsolete. The only justification for that (these days) which I can think of is Unicode fonts.

> I was using TortoiseHg before with BitBucket.
> 
> as noted before, the main killer was the long upload times

Dunno if this is due to large data (initial commit) or just Python being slow. Or maybe it's your network. Git claims to be uber fast, but who knows ....

> it seemed to want nit-picky things, like creating a new version entry 
> and typing something in the changelog, before it would commit anything.

Well, that's the whole point. I'm only vaguely starting to understand it. Apparently you want to mention when you cleaned up some stuff, fixed a certain bug, added an initial attempt at a specific feature, etc. It's more about being able to look back and easily understand what / why / how you did something, esp. if you need to revert a regression.

(If you had multiple projects using multiple version controls, something like Emacs' VC-Mode [or whatever it's called] would be useful, assuming you can live with the bloat that is Emacs.)
 
> granted, yes, it could be about learning curve or settings or something, 
> but in this case, it doesn't make a good case for it being less of a hassle.

RCS sounds like the simplest for offline, single developer. It's portable, too. It automatically stores diffs of your files. I think this would save space over random .ZIPs (though using a better tool like 7-Zip, solid archiving, might lessen that advantage).

> less effort depends a lot on situation, like for multiple developers, it 
> is probably a lot less effort to use version-control, than deal with the 
> hassle that is emailing around code and/or dealing with diff patches.

Linus lived without version control for years. But yeah, with lots of different authors, regressions, and merging incompatible changes, version control seems like an obvious win.

> for a single developer though, it is harder pressed that it is less 
> effort, since a lone developer hardly ever has reason to diff their own 
> code.

Maybe you want to see why something slowed down, or why it stopped working. Or maybe you just want to compare to older versions to make sure the code doesn't need to be refactored some more.

[toc] | [prev] | [next] | [standalone]

#2706

BGB wrote:
> On 12/30/2012 6:00 PM, Ian Collins wrote:
>> BGB wrote:
>>> On 12/30/2012 2:36 PM, Ian Collins wrote:
>>>> BGB wrote:
>>>>>
>>>>> granted, but it isn't really all that clear if/how it is worth the
>>>>> hassle of doing so.
>>>>
>>>> The "hassle" of typing "hg commit" once in a while is far outweighed by
>>>> the convenience of being able to type "hg revert" when you break
>>>> something.
>>>>
>>>
>>> or, a person can be systematic, and manually revert the last changes
>>> they made (this being a big win for "#if 0" and "#if 1")
>>>
>>> or, maybe just hit CTRL-Z a few times (if the breaking change was
>>> recent).
>>>
>>> if by some chance they really screw up, copy/paste files from an older
>>> version.
>>
>> So that's all less hassle than "hg revert"?
>>
>
> partly yes, because usually this can be done via the GUI, whereas typing
> in "hg revert" could very well involve bringing up a shell, changing to
> the right path, and typing it in.
>
> granted, TorgoiseHg adds revert to Explorer, making the above a bit moot.

As do popular IDEs such as Eclipse and Netbeans.

> the rest would come down mostly to granularity.
> (like, if you revert, it will go back to the last commit, meaning being
> strategic about when to commit, ...).

You commit when you pass a test or refactor.

> guards, however, can be finer-grained, and can be enabled/disabled at
> will, rather than depending specifically on the immediate history.

If you need lots of them, you are doing something wrong.

> and, CTRL-Z is about specific edits, meaning it can undo very recent
> changes, and go as far back (usually) as there are undo levels, or when
> the editor was last closed and reopened (whichever was more recent).

A pain in the arse if you want to undo changes in several files.

> it is much like the tradeoff between using Find/Replace and grep or sed.
>
> Find/Replace is often easier, because it it right there in the editor.

Again, popular IDEs support project wide edits and common refactorings.

> the convenience balance may be partly reversed on Linux though,

There are more than two operating systems....

>>>> As for copying, with Mercurial at least, everything in in the source
>>>> directory, so there's no additional effort required.  Because you don't
>>>> have all those dated directories floating around, where's way less data
>>>> to copy.
>>>>
>>>> The convenience of being able to use ssh to clone and synchronise
>>>> between hosts and devices is a big win.
>>>>
>>>
>>> you can also transfer things using, say, FTP, or network shares (if on a
>>> LAN). (granted, yes, a person needs an FTP server for the FTP route).
>>
>> Share maybe, but handle merging?  Branches?
>>
>
> not usually a big issue for a single developer project.
>
> more so, if the developer does the bulk of their development from a
> single computer (which then generally holds the "authoritative" copy).
>
> more often, if I am going to be away, and have a laptop, I will usually
> make a copy on an external HDD (or "USB Mass Storage Device"), then if I
> work on it more, that version will become the authoritative copy, at
> least until I copy it back onto my main computer.

Using hg push/pull to/from external storage is a lot quicker than 
copying the whole tree.

>>> as-is though, both my main computer and web-server are running Windows...
>>
>> So share your repository via http(s)!
>>
>> You can use Tortoise HG to pull from or push to remote repositories on
>> windows.  You should try it (or Tortoise SVN) some time, it is an
>> excellent application.
>>
>
> I was using TortoiseHg before with BitBucket.
>
> as noted before, the main killer was the long upload times, and because
> it seemed to want nit-picky things, like creating a new version entry
> and typing something in the changelog, before it would commit anything.

Ah yes, good development practice!

The long upload times would be down to the Internet, not Mercurial.  It 
will only copy changes.  This can be a big advantage when you make a 
small change to a big file over a slow link.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2707

On 12/31/2012 2:05 PM, Ian Collins wrote:
> BGB wrote:
>> On 12/30/2012 6:00 PM, Ian Collins wrote:
>>> BGB wrote:
>>>> On 12/30/2012 2:36 PM, Ian Collins wrote:
>>>>> BGB wrote:
>>>>>>
>>>>>> granted, but it isn't really all that clear if/how it is worth the
>>>>>> hassle of doing so.
>>>>>
>>>>> The "hassle" of typing "hg commit" once in a while is far
>>>>> outweighed by
>>>>> the convenience of being able to type "hg revert" when you break
>>>>> something.
>>>>>
>>>>
>>>> or, a person can be systematic, and manually revert the last changes
>>>> they made (this being a big win for "#if 0" and "#if 1")
>>>>
>>>> or, maybe just hit CTRL-Z a few times (if the breaking change was
>>>> recent).
>>>>
>>>> if by some chance they really screw up, copy/paste files from an older
>>>> version.
>>>
>>> So that's all less hassle than "hg revert"?
>>>
>>
>> partly yes, because usually this can be done via the GUI, whereas typing
>> in "hg revert" could very well involve bringing up a shell, changing to
>> the right path, and typing it in.
>>
>> granted, TorgoiseHg adds revert to Explorer, making the above a bit moot.
>
> As do popular IDEs such as Eclipse and Netbeans.
>

Eclipse with C or C++ kind of sucked IME, and doesn't seem to support 
using MSVC as the back-end compiler (the version I looked at only 
supported GCC as a backend, and wasn't really all that configurable).

never tried Netbeans, wasn't aware of it working with non-Java languages...


>> the rest would come down mostly to granularity.
>> (like, if you revert, it will go back to the last commit, meaning being
>> strategic about when to commit, ...).
>
> You commit when you pass a test or refactor.
>

this could potentially still be a fairly coarse granularity.


>> guards, however, can be finer-grained, and can be enabled/disabled at
>> will, rather than depending specifically on the immediate history.
>
> If you need lots of them, you are doing something wrong.
>

usually, a lot is about fine-tuning the behavior or performance.

say, a person has 2 or 3 versions of a piece of code, which may approach 
the problem in slightly different ways, and the goal may be to figure 
out which is faster, or has the more desirable behavior.

once it gets pretty much settled, the other versions may be discarded.


>> and, CTRL-Z is about specific edits, meaning it can undo very recent
>> changes, and go as far back (usually) as there are undo levels, or when
>> the editor was last closed and reopened (whichever was more recent).
>
> A pain in the arse if you want to undo changes in several files.
>

usually, in this case (a change which would need to be reverted in 
multiple places), these will be put under the control of a define:
#define MYLIB_SOMEFEATURE

otherwise, it makes sense to try to avoid changes which may effect code 
in multiple locations.

if a more drastic set of changes needs to be done, it is usually at this 
point that the directory is cloned, creating a new "version" of the 
given library, which control may be changed over to once these changes 
are "reasonably complete".

an alternate (sometimes used) strategy, is to make a backup copy, and 
keep this backup around until these modifications seem to be holding up.


>> it is much like the tradeoff between using Find/Replace and grep or sed.
>>
>> Find/Replace is often easier, because it it right there in the editor.
>
> Again, popular IDEs support project wide edits and common refactorings.
>

I typically use stand-alone text-editors.

I could use Visual Studio more often, if I wanted the IDE experience.


>> the convenience balance may be partly reversed on Linux though,
>
> There are more than two operating systems....
>

well, there are Windows, Linux, and OSX.

much beyond this, it is hard-pressed to find "anyone who gives a crap".
it is like, how many people use FreeBSD? not really enough to matter.

other options, like Android or Chrome, don't really count, in that they 
are Linux-based.


>>>>> As for copying, with Mercurial at least, everything in in the source
>>>>> directory, so there's no additional effort required.  Because you
>>>>> don't
>>>>> have all those dated directories floating around, where's way less
>>>>> data
>>>>> to copy.
>>>>>
>>>>> The convenience of being able to use ssh to clone and synchronise
>>>>> between hosts and devices is a big win.
>>>>>
>>>>
>>>> you can also transfer things using, say, FTP, or network shares (if
>>>> on a
>>>> LAN). (granted, yes, a person needs an FTP server for the FTP route).
>>>
>>> Share maybe, but handle merging?  Branches?
>>>
>>
>> not usually a big issue for a single developer project.
>>
>> more so, if the developer does the bulk of their development from a
>> single computer (which then generally holds the "authoritative" copy).
>>
>> more often, if I am going to be away, and have a laptop, I will usually
>> make a copy on an external HDD (or "USB Mass Storage Device"), then if I
>> work on it more, that version will become the authoritative copy, at
>> least until I copy it back onto my main computer.
>
> Using hg push/pull to/from external storage is a lot quicker than
> copying the whole tree.
>

could be, but it usually isn't a big deal...

a few seconds or minutes usually isn't a huge issue.


>>>> as-is though, both my main computer and web-server are running
>>>> Windows...
>>>
>>> So share your repository via http(s)!
>>>
>>> You can use Tortoise HG to pull from or push to remote repositories on
>>> windows.  You should try it (or Tortoise SVN) some time, it is an
>>> excellent application.
>>>
>>
>> I was using TortoiseHg before with BitBucket.
>>
>> as noted before, the main killer was the long upload times, and because
>> it seemed to want nit-picky things, like creating a new version entry
>> and typing something in the changelog, before it would commit anything.
>
> Ah yes, good development practice!
>

yes, but it doesn't save in annoyance, especially if the whole point is 
that a person commits regularly.

most likely, a person will end up with a whole lot of "fiddling with X" 
or "trying to optimize Y", or occasionally "fixed bug Z".


> The long upload times would be down to the Internet, not Mercurial.  It
> will only copy changes.  This can be a big advantage when you make a
> small change to a big file over a slow link.
>

IME, it was typically uploading a lot of data each time.


granted, maybe, endlessly copying ones' entire codebase over the 
internet would be slower, but OTOH, for local storage it isn't really a 
big issue... (and modern HDDs are big enough that this isn't really a 
big issue either).

over a LAN, it is a bit slower, which is more typically why either it 
isn't done when time matters (I can just go do something else while it 
copies), or a USB HDD can be used instead (because the USB HDD is faster).

(like, one gets 15-20MB/s for a USB HDD, but only about 5-7MB/s over a 
LAN, or 2-4 MB/s over WiFi).


could be faster though, if one is using a wired connection and all of 
the parts support 1GbE (vs only 100baseT or similar...).

in past cases where I was able to copy between computers using 1GbE, it 
performed essentially about as fast as local file-copying.

[toc] | [prev] | [next] | [standalone]

#2708

BGB wrote:
> On 12/31/2012 2:05 PM, Ian Collins wrote:
>> BGB wrote:
>>>
>>> granted, TorgoiseHg adds revert to Explorer, making the above a bit moot.
>>
>> As do popular IDEs such as Eclipse and Netbeans.
>>
>
> Eclipse with C or C++ kind of sucked IME, and doesn't seem to support
> using MSVC as the back-end compiler (the version I looked at only
> supported GCC as a backend, and wasn't really all that configurable).
>
> never tried Netbeans, wasn't aware of it working with non-Java languages...

I use Netbeans on various platforms for C, C++, PHP and JavaScript.  It 
has good support (including background compilation) for all four of them.

>>> the rest would come down mostly to granularity.
>>> (like, if you revert, it will go back to the last commit, meaning being
>>> strategic about when to commit, ...).
>>
>> You commit when you pass a test or refactor.
>>
>
> this could potentially still be a fairly coarse granularity.

In my case, 10 - 20 times an hour.

>>> guards, however, can be finer-grained, and can be enabled/disabled at
>>> will, rather than depending specifically on the immediate history.
>>
>> If you need lots of them, you are doing something wrong.
>>
>
> usually, a lot is about fine-tuning the behavior or performance.
>
> say, a person has 2 or 3 versions of a piece of code, which may approach
> the problem in slightly different ways, and the goal may be to figure
> out which is faster, or has the more desirable behavior.

Use branches, merge when done.

>>> and, CTRL-Z is about specific edits, meaning it can undo very recent
>>> changes, and go as far back (usually) as there are undo levels, or when
>>> the editor was last closed and reopened (whichever was more recent).
>>
>> A pain in the arse if you want to undo changes in several files.
>
> usually, in this case (a change which would need to be reverted in
> multiple places), these will be put under the control of a define:
> #define MYLIB_SOMEFEATURE

You still have to clean up afterwards.

>>> it is much like the tradeoff between using Find/Replace and grep or sed.
>>>
>>> Find/Replace is often easier, because it it right there in the editor.
>>
>> Again, popular IDEs support project wide edits and common refactorings.
>
> I typically use stand-alone text-editors.
>
> I could use Visual Studio more often, if I wanted the IDE experience.

There's plenty of choice out there.

>>> the convenience balance may be partly reversed on Linux though,
>>
>> There are more than two operating systems....
>>
>
> well, there are Windows, Linux, and OSX.
>
> much beyond this, it is hard-pressed to find "anyone who gives a crap".
> it is like, how many people use FreeBSD? not really enough to matter.

If just about every ISP doesn't matter....

> other options, like Android or Chrome, don't really count, in that they
> are Linux-based.

There are still a lot of us working on commercial and other open source 
UNIX.

>>> as noted before, the main killer was the long upload times, and because
>>> it seemed to want nit-picky things, like creating a new version entry
>>> and typing something in the changelog, before it would commit anything.
>>
>> Ah yes, good development practice!
>>
>
> yes, but it doesn't save in annoyance, especially if the whole point is
> that a person commits regularly.

Not really, if your changes are small, so are your comments.

>> The long upload times would be down to the Internet, not Mercurial.  It
>> will only copy changes.  This can be a big advantage when you make a
>> small change to a big file over a slow link.
>>
>
> IME, it was typically uploading a lot of data each time.

The best demo I used (with SVN) was to check out a big spreadsheet over 
a slow VPN, change one cell and commit it back.  Copying over the VPN 
took a couple of minutes, the SVN commit took a few seconds to send the 
delta.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2711

BGB wrote:

> On 12/30/2012 6:00 PM, Ian Collins wrote:
>>
>> So that's all less hassle than "hg revert"?
>>
> 
> partly yes, because usually this can be done via the GUI, whereas typing
> in "hg revert" could very well involve bringing up a shell, changing to
> the right path, and typing it in.

Using a shell tends to be a bit better because it gives more control to the 
user, and can be more efficient.  For example, typing "git checkout branch" 
can be done faster than navigating a menu.

Regarding the "bringing up a shell" bit, essentially this costs the same as 
bringing up any other GUI application, such as a FTP client or a file 
manager. 


> granted, TorgoiseHg adds revert to Explorer, making the above a bit moot.
> 
> 
> the rest would come down mostly to granularity.
> (like, if you revert, it will go back to the last commit, meaning being
> strategic about when to commit, ...).

You can checkout any version you've committed from any development branch.  
Some version control systems such as Git also provide a nifty feature: 
stashing away changes that weren't committed in a temporary stack.  
Mercurial also supports this feature, but only as an extension.


<snip/>
>>>> As for copying, with Mercurial at least, everything in in the source
>>>> directory, so there's no additional effort required.  Because you don't
>>>> have all those dated directories floating around, where's way less data
>>>> to copy.
>>>>
>>>> The convenience of being able to use ssh to clone and synchronise
>>>> between hosts and devices is a big win.
>>>>
>>>
>>> you can also transfer things using, say, FTP, or network shares (if on a
>>> LAN). (granted, yes, a person needs an FTP server for the FTP route).
>>
>> Share maybe, but handle merging?  Branches?
>>
> 
> not usually a big issue for a single developer project.
> 
> more so, if the developer does the bulk of their development from a
> single computer (which then generally holds the "authoritative" copy).
> 
> more often, if I am going to be away, and have a laptop, I will usually
> make a copy on an external HDD (or "USB Mass Storage Device"), then if I
> work on it more, that version will become the authoritative copy, at
> least until I copy it back onto my main computer.

Development branches are useful even in single-developer projects.  They let 
you have multiple development branches which can be easily merged and 
forked.  The best part of it is that versioned history can be kept between 
merges.


> for a single developer though, it is harder pressed that it is less
> effort, since a lone developer hardly ever has reason to diff their own
> code.

Not necessarily.  If you track changes to your project tree, and if by any 
chance one of those changes happens to introduce a bug, a version control 
system lets you pinpoint which change introduced the bug, and you can 
quickly inspect what changes were made by diff'ing between any couple of 
versions.  With a version control system, you can do all this without having 
to checkout anything.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2712

On 1/2/2013 6:23 AM, Rui Maciel wrote:
> BGB wrote:
>
>> On 12/30/2012 6:00 PM, Ian Collins wrote:
>>>
>>> So that's all less hassle than "hg revert"?
>>>
>>
>> partly yes, because usually this can be done via the GUI, whereas typing
>> in "hg revert" could very well involve bringing up a shell, changing to
>> the right path, and typing it in.
>
> Using a shell tends to be a bit better because it gives more control to the
> user, and can be more efficient.  For example, typing "git checkout branch"
> can be done faster than navigating a menu.
>
> Regarding the "bringing up a shell" bit, essentially this costs the same as
> bringing up any other GUI application, such as a FTP client or a file
> manager.
>

the advantage of the GUI based option though is that usually a person 
can click on things faster than they can type things.

this is mostly an issue of having longish paths to 'cd' through, making 
getting to the desired directory take a little longer (meaning a higher 
initial cost).


this means that navigating to a directory, or moving between 
directories, can be done faster and easier in Windows Explorer than in a 
shell.

( granted, right now, I can observe that I have around 30 copies of 
Windows Explorer open, each currently pointing to a different directory. 
nevermind that the current number of open text editors is in the "stack 
doesn't fit on screen and Windows scrolls very slowly" territory. )


granted, a better option would be if Explorer had an "Open CMD Shell 
Here" option. (or, even, the ability to, like in Linux, open a new shell 
in the same directory as the prior shell...).

but, even then, there would be a secondary annoyance:
MS configures their compiler via environment variables used in the batch 
file used to open the shell (rather than, say, putting the compiler on 
the default path and using an INI file or similar for config). granted, 
OTOH, it does make MSVC a little easier to auto-configure tools against 
than GCC (which would externally appear to use magic to know its 
settings...).

the issue here is that an "open shell here" would then not be nearly so 
useful if the intent is to rebuild the project...


>
>> granted, TorgoiseHg adds revert to Explorer, making the above a bit moot.
>>
>>
>> the rest would come down mostly to granularity.
>> (like, if you revert, it will go back to the last commit, meaning being
>> strategic about when to commit, ...).
>
> You can checkout any version you've committed from any development branch.
> Some version control systems such as Git also provide a nifty feature:
> stashing away changes that weren't committed in a temporary stack.
> Mercurial also supports this feature, but only as an extension.
>

ok.


as-is, I currently have 3 branches of my VM's interpreter:
the original / current live version;
a version which I tried to rewrite to use untagged values, but ran into 
problems I can't yet address (there are still holes in the type-system, 
which is a killer for untagged values);
another version, which I am in the process of migrating from the 
original tagged pointers, to a new tagged-reference system (where the 
references are always 64-bits), mostly as the prior effort ran into a 
wall (64-bit tagged references allow unboxed int/float/double on 32-bit 
targets, although sadly, not an unboxed 64-bit long).


but, how am I managing these branches:
well, via copies of the directory tree.

if this new branch gets written and working, it may then be substituted 
in, in place of the original.


>
> <snip/>
>>>>> As for copying, with Mercurial at least, everything in in the source
>>>>> directory, so there's no additional effort required.  Because you don't
>>>>> have all those dated directories floating around, where's way less data
>>>>> to copy.
>>>>>
>>>>> The convenience of being able to use ssh to clone and synchronise
>>>>> between hosts and devices is a big win.
>>>>>
>>>>
>>>> you can also transfer things using, say, FTP, or network shares (if on a
>>>> LAN). (granted, yes, a person needs an FTP server for the FTP route).
>>>
>>> Share maybe, but handle merging?  Branches?
>>>
>>
>> not usually a big issue for a single developer project.
>>
>> more so, if the developer does the bulk of their development from a
>> single computer (which then generally holds the "authoritative" copy).
>>
>> more often, if I am going to be away, and have a laptop, I will usually
>> make a copy on an external HDD (or "USB Mass Storage Device"), then if I
>> work on it more, that version will become the authoritative copy, at
>> least until I copy it back onto my main computer.
>
> Development branches are useful even in single-developer projects.  They let
> you have multiple development branches which can be easily merged and
> forked.  The best part of it is that versioned history can be kept between
> merges.
>

yes, but this can also be done (more or less) via copies, and is "part 
of the process".


>
>> for a single developer though, it is harder pressed that it is less
>> effort, since a lone developer hardly ever has reason to diff their own
>> code.
>
> Not necessarily.  If you track changes to your project tree, and if by any
> chance one of those changes happens to introduce a bug, a version control
> system lets you pinpoint which change introduced the bug, and you can
> quickly inspect what changes were made by diff'ing between any couple of
> versions.  With a version control system, you can do all this without having
> to checkout anything.
>

granted.

rebuilding / retesting after nearly every change (at least to the "live" 
version) can also help reduce bugs though (granted, yes, this may take 
many minutes each time this is done).


either way though...


>
> Rui Maciel
>

[toc] | [prev] | [next] | [standalone]

#2715

On Wed, 02 Jan 2013 14:34:51 -0600, BGB <cr88192@hotmail.com> wrote:

>On 1/2/2013 6:23 AM, Rui Maciel wrote:
>> Using a shell tends to be a bit better because it gives more control to the
>> user, and can be more efficient.  For example, typing "git checkout branch"
>> can be done faster than navigating a menu.
>>
>> Regarding the "bringing up a shell" bit, essentially this costs the same as
>> bringing up any other GUI application, such as a FTP client or a file
>> manager.
>>
>
>the advantage of the GUI based option though is that usually a person 
>can click on things faster than they can type things.
>
>this is mostly an issue of having longish paths to 'cd' through, making 
>getting to the desired directory take a little longer (meaning a higher 
>initial cost).
>
>
>this means that navigating to a directory, or moving between 
>directories, can be done faster and easier in Windows Explorer than in a 
>shell.
>
>( granted, right now, I can observe that I have around 30 copies of 
>Windows Explorer open, each currently pointing to a different directory. 
>nevermind that the current number of open text editors is in the "stack 
>doesn't fit on screen and Windows scrolls very slowly" territory. )
>
>
>granted, a better option would be if Explorer had an "Open CMD Shell 
>Here" option. (or, even, the ability to, like in Linux, open a new shell 
>in the same directory as the prior shell...).


If you're using Vista or later, hold the shift key when you
right-click the directory in Explorer.

In XP there's a doshere or cmdhere program that's part of Windows
Powertoys.  Or there's  simple registry change.  Actually that's all
the cmdhere is anyway, it's an .inf ("cmdhere.inf") file that has the
install/uninstall scripts for the registry settings.  There are
versions people have done for post-XP systems as well.


>but, even then, there would be a secondary annoyance:
>MS configures their compiler via environment variables used in the batch 
>file used to open the shell (rather than, say, putting the compiler on 
>the default path and using an INI file or similar for config). granted, 
>OTOH, it does make MSVC a little easier to auto-configure tools against 
>than GCC (which would externally appear to use magic to know its 
>settings...).
>
>the issue here is that an "open shell here" would then not be nearly so 
>useful if the intent is to rebuild the project...


Once you get the cmdhere.inf (or other appropriate version for post-XP
systems), you can trivially modify it to add different commands, and
different invocations of cmd.  Note that there are several, depending
on what object you're seeing in explorer (file folver, vs. drive,
etc).  I have a couple that change invoke something like:

  cmd.exe /k cd ""%1""" & c:\somebatchfile

And if you make the changes with a modicum of care, you'll get full
uninstall support.

Or just look under HKCR\Drive\Shell and HKCR\Directory\Shell, you
should find some samples to modify.  For example, you could add the
following strings under the indicated keys:

  HKCR\Directory\Shell\mycmd
     (default)="Open My CMD &Window"
  HKCR\Directory\Shell\mycmd\command
     (default)="C:\WINDOWS\system32\cmd.exe /k cd "%1" & c:\mybat"

note the & in front of "Window" adds an accelerator key, and is not
necessary if you don't want one.

(similar entries under HKCR\Drive)

[toc] | [prev] | [next] | [standalone]

#2724

On 1/2/2013 3:35 PM, Robert Wessel wrote:
> On Wed, 02 Jan 2013 14:34:51 -0600, BGB <cr88192@hotmail.com> wrote:
>
>> On 1/2/2013 6:23 AM, Rui Maciel wrote:
>>> Using a shell tends to be a bit better because it gives more control to the
>>> user, and can be more efficient.  For example, typing "git checkout branch"
>>> can be done faster than navigating a menu.
>>>
>>> Regarding the "bringing up a shell" bit, essentially this costs the same as
>>> bringing up any other GUI application, such as a FTP client or a file
>>> manager.
>>>
>>
>> the advantage of the GUI based option though is that usually a person
>> can click on things faster than they can type things.
>>
>> this is mostly an issue of having longish paths to 'cd' through, making
>> getting to the desired directory take a little longer (meaning a higher
>> initial cost).
>>
>>
>> this means that navigating to a directory, or moving between
>> directories, can be done faster and easier in Windows Explorer than in a
>> shell.
>>
>> ( granted, right now, I can observe that I have around 30 copies of
>> Windows Explorer open, each currently pointing to a different directory.
>> nevermind that the current number of open text editors is in the "stack
>> doesn't fit on screen and Windows scrolls very slowly" territory. )
>>
>>
>> granted, a better option would be if Explorer had an "Open CMD Shell
>> Here" option. (or, even, the ability to, like in Linux, open a new shell
>> in the same directory as the prior shell...).
>
>
> If you're using Vista or later, hold the shift key when you
> right-click the directory in Explorer.
>

yep, confirmed...

though granted it is the standard CMD shell.
probably useful enough for a lot of things...


> In XP there's a doshere or cmdhere program that's part of Windows
> Powertoys.  Or there's  simple registry change.  Actually that's all
> the cmdhere is anyway, it's an .inf ("cmdhere.inf") file that has the
> install/uninstall scripts for the registry settings.  There are
> versions people have done for post-XP systems as well.
>

ok.

>
>> but, even then, there would be a secondary annoyance:
>> MS configures their compiler via environment variables used in the batch
>> file used to open the shell (rather than, say, putting the compiler on
>> the default path and using an INI file or similar for config). granted,
>> OTOH, it does make MSVC a little easier to auto-configure tools against
>> than GCC (which would externally appear to use magic to know its
>> settings...).
>>
>> the issue here is that an "open shell here" would then not be nearly so
>> useful if the intent is to rebuild the project...
>
>
> Once you get the cmdhere.inf (or other appropriate version for post-XP
> systems), you can trivially modify it to add different commands, and
> different invocations of cmd.  Note that there are several, depending
> on what object you're seeing in explorer (file folver, vs. drive,
> etc).  I have a couple that change invoke something like:
>
>    cmd.exe /k cd ""%1""" & c:\somebatchfile
>
> And if you make the changes with a modicum of care, you'll get full
> uninstall support.
>
> Or just look under HKCR\Drive\Shell and HKCR\Directory\Shell, you
> should find some samples to modify.  For example, you could add the
> following strings under the indicated keys:
>
>    HKCR\Directory\Shell\mycmd
>       (default)="Open My CMD &Window"
>    HKCR\Directory\Shell\mycmd\command
>       (default)="C:\WINDOWS\system32\cmd.exe /k cd "%1" & c:\mybat"
>
> note the & in front of "Window" adds an accelerator key, and is not
> necessary if you don't want one.
>
> (similar entries under HKCR\Drive)
>

nifty, ...

will have to look into this.

[toc] | [prev] | [next] | [standalone]

#2716

BGB wrote:
) the advantage of the GUI based option though is that usually a person 
) can click on things faster than they can type things.

On average, perhaps.  But looking at programmers or other power users, the
average is the other way around.  They can usually type things faster than
they can click on things.  Which is why every menu has a keyboard shortcut.

) this is mostly an issue of having longish paths to 'cd' through, making 
) getting to the desired directory take a little longer (meaning a higher 
) initial cost).

Longish paths can be tab-completed, if you have the right shell.
I'm way faster into a directory if I can just type it in with
tab-completion.

) this means that navigating to a directory, or moving between 
) directories, can be done faster and easier in Windows Explorer than in a 
) shell.

Me experience is otherwise.

) granted, a better option would be if Explorer had an "Open CMD Shell 
) Here" option. (or, even, the ability to, like in Linux, open a new shell 
) in the same directory as the prior shell...).

There are tools to add that option.  You can make one yourself with just a
bit of windows api knowledge.

) but, even then, there would be a secondary annoyance:
) MS configures their compiler via environment variables used in the batch 
) file used to open the shell (rather than, say, putting the compiler on 
) the default path and using an INI file or similar for config). granted, 
) OTOH, it does make MSVC a little easier to auto-configure tools against 
) than GCC (which would externally appear to use magic to know its 
) settings...).
)
) the issue here is that an "open shell here" would then not be nearly so 
) useful if the intent is to rebuild the project...

Then you add an 'open shell here' which uses that batch file.

) as-is, I currently have 3 branches of my VM's interpreter:
) the original / current live version;
) a version which I tried to rewrite to use untagged values, but ran into 
) problems I can't yet address (there are still holes in the type-system, 
) which is a killer for untagged values);
) another version, which I am in the process of migrating from the 
) original tagged pointers, to a new tagged-reference system (where the 
) references are always 64-bits), mostly as the prior effort ran into a 
) wall (64-bit tagged references allow unboxed int/float/double on 32-bit 
) targets, although sadly, not an unboxed 64-bit long).
)
)
) but, how am I managing these branches:
) well, via copies of the directory tree.
)
) if this new branch gets written and working, it may then be substituted 
) in, in place of the original.

You can do all that with a VCS as well.  And then you can merge both
directory trees together and get all the changes in one place.

)> Development branches are useful even in single-developer projects.  They let
)> you have multiple development branches which can be easily merged and
)> forked.  The best part of it is that versioned history can be kept between
)> merges.
)>
)
) yes, but this can also be done (more or less) via copies, and is "part 
) of the process".

Yes, but a version control system makes this easier for you.
You *can* do anything the hard way, that's not a reason to keep doing it
like that.

)> Not necessarily.  If you track changes to your project tree, and if by any
)> chance one of those changes happens to introduce a bug, a version control
)> system lets you pinpoint which change introduced the bug, and you can
)> quickly inspect what changes were made by diff'ing between any couple of
)> versions.  With a version control system, you can do all this without having
)> to checkout anything.
)>
)
) granted.
)
) rebuilding / retesting after nearly every change (at least to the "live" 
) version) can also help reduce bugs though (granted, yes, this may take 
) many minutes each time this is done).

With a VCS, you can set up a continuous integration system, which do this
in the background and send you an email if a build or automatic test fails.
(Or send you a message in an IM system, or cause a popup on your screen.)


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#2725

On 1/3/2013 2:35 AM, Willem wrote:
> BGB wrote:
> ) the advantage of the GUI based option though is that usually a person
> ) can click on things faster than they can type things.
>
> On average, perhaps.  But looking at programmers or other power users, the
> average is the other way around.  They can usually type things faster than
> they can click on things.  Which is why every menu has a keyboard shortcut.
>

keyboard shortcuts are faster, but keyboard shortcuts aren't really typing.

I actually prefer shortcuts over "big dumb forms and button-driven 
GUIs", but Windows Explorer is a bit more clever of a GUI than this, and 
is reasonably streamlined for what it does.


> ) this is mostly an issue of having longish paths to 'cd' through, making
> ) getting to the desired directory take a little longer (meaning a higher
> ) initial cost).
>
> Longish paths can be tab-completed, if you have the right shell.
> I'm way faster into a directory if I can just type it in with
> tab-completion.
>

yep, there is also '*', but this requires typing enough of the directory 
that it can be correctly identified via its prefix.


interestingly, my in-program console has tab-completion, where it tends 
to display a ghosted-out version of what it will expand to when the user 
hits tab.


> ) this means that navigating to a directory, or moving between
> ) directories, can be done faster and easier in Windows Explorer than in a
> ) shell.
>
> Me experience is otherwise.
>

I will disagree.


> ) granted, a better option would be if Explorer had an "Open CMD Shell
> ) Here" option. (or, even, the ability to, like in Linux, open a new shell
> ) in the same directory as the prior shell...).
>
> There are tools to add that option.  You can make one yourself with just a
> bit of windows api knowledge.
>
> ) but, even then, there would be a secondary annoyance:
> ) MS configures their compiler via environment variables used in the batch
> ) file used to open the shell (rather than, say, putting the compiler on
> ) the default path and using an INI file or similar for config). granted,
> ) OTOH, it does make MSVC a little easier to auto-configure tools against
> ) than GCC (which would externally appear to use magic to know its
> ) settings...).
> )
> ) the issue here is that an "open shell here" would then not be nearly so
> ) useful if the intent is to rebuild the project...
>
> Then you add an 'open shell here' which uses that batch file.
>

seems so.


> ) as-is, I currently have 3 branches of my VM's interpreter:
> ) the original / current live version;
> ) a version which I tried to rewrite to use untagged values, but ran into
> ) problems I can't yet address (there are still holes in the type-system,
> ) which is a killer for untagged values);
> ) another version, which I am in the process of migrating from the
> ) original tagged pointers, to a new tagged-reference system (where the
> ) references are always 64-bits), mostly as the prior effort ran into a
> ) wall (64-bit tagged references allow unboxed int/float/double on 32-bit
> ) targets, although sadly, not an unboxed 64-bit long).
> )
> )
> ) but, how am I managing these branches:
> ) well, via copies of the directory tree.
> )
> ) if this new branch gets written and working, it may then be substituted
> ) in, in place of the original.
>
> You can do all that with a VCS as well.  And then you can merge both
> directory trees together and get all the changes in one place.
>
> )> Development branches are useful even in single-developer projects.  They let
> )> you have multiple development branches which can be easily merged and
> )> forked.  The best part of it is that versioned history can be kept between
> )> merges.
> )>
> )
> ) yes, but this can also be done (more or less) via copies, and is "part
> ) of the process".
>
> Yes, but a version control system makes this easier for you.
> You *can* do anything the hard way, that's not a reason to keep doing it
> like that.
>
> )> Not necessarily.  If you track changes to your project tree, and if by any
> )> chance one of those changes happens to introduce a bug, a version control
> )> system lets you pinpoint which change introduced the bug, and you can
> )> quickly inspect what changes were made by diff'ing between any couple of
> )> versions.  With a version control system, you can do all this without having
> )> to checkout anything.
> )>
> )
> ) granted.
> )
> ) rebuilding / retesting after nearly every change (at least to the "live"
> ) version) can also help reduce bugs though (granted, yes, this may take
> ) many minutes each time this is done).
>
> With a VCS, you can set up a continuous integration system, which do this
> in the background and send you an email if a build or automatic test fails.
> (Or send you a message in an IM system, or cause a popup on your screen.)
>

yep, fair enough.

I have some automatic tests, and some amount of interactive tests 
(since, for example, testing things like 3D rendering or game-mechanics 
is kind of hard to automate).

so, one may end up with a delay:
rebuild 3D engine;
start up and run around for maybe a minute or a few minutes, verifying 
that everything looks about right.

sometimes, this sort of testing may miss some kinds of bugs though, like 
if one always tests with various cheat-codes enabled, they may fail to 
notice when non-cheating mechanics break (like, for example, the enemies 
firing off rockets which fail to do any damage, or on character death, 
re-spawning fails to work correctly, ...).


in a few cases, bugs are found in areas which hadn't really been used or 
tested previously, like finding edge-cases in script language syntax or 
behavior, ...


but, alas...

[toc] | [prev] | [next] | [standalone]

#2717

Hi,

On Wednesday, January 2, 2013 2:34:51 PM UTC-6, BGB wrote:
> 
> the advantage of the GUI based option though is that usually a person 
> can click on things faster than they can type things.
> 
> this is mostly an issue of having longish paths to 'cd' through, making 
> getting to the desired directory take a little longer (meaning a higher 
> initial cost).
> 
> this means that navigating to a directory, or moving between 
> directories, can be done faster and easier in Windows Explorer than in a 
> shell.

Depends on how you set everything up. You could set up a few shell aliases (doskey macros) or .BAT files to switch back and forth where needed, esp. using CMD's "pushd" and "popd". Or use a third-party util like "wcd". Also, CMD supports wildcards, so you can "cd tm*\mis*".

I haven't used NDN a lot lately, but IIRC it had a few shortcuts (e.g. Alt-0 or Alt-9 or whatever) for jumping around certain predefined subdirs. And this is not counting the obvious file manager part (which can have several separate manager windows at the same time for different views). Similarly Emacs' Dired can jump around fairly painlessly too, if you're willing to go that route.
 
> ( granted, right now, I can observe that I have around 30 copies of 
> Windows Explorer open, each currently pointing to a different directory. 
> 
> nevermind that the current number of open text editors is in the "stack 
> doesn't fit on screen and Windows scrolls very slowly" territory. )

While "whatever works" is fine, be aware that Emacs and NDN both have their own text editors (more obviously the former), so they may be more productive for you. But of course there's more than one way to skin a cat.
 
> granted, a better option would be if Explorer had an "Open CMD Shell 
> Here" option. (or, even, the ability to, like in Linux, open a new shell 
> in the same directory as the prior shell...).

With Emacs, you run "eshell" or just "shell" or similar. With NDN, the shell is always available (though not with cmdline macros, sadly). And both (IIRC) have interactive macro capability to automate some things. Granted, Emacs is more scriptable, but I'm not sure that's worth your time (or mine or ...).

> but, even then, there would be a secondary annoyance:
> 
> MS configures their compiler via environment variables used in the batch 
> file used to open the shell (rather than, say, putting the compiler on 
> the default path and using an INI file or similar for config). granted, 
> OTOH, it does make MSVC a little easier to auto-configure tools against 
> than GCC (which would externally appear to use magic to know its 
> settings...).

I'd be surprised if nobody got MSVC working with Emacs. I'm pretty sure M-x compile works with GCC, though.  ;-)

[toc] | [prev] | [next] | [standalone]

#2719

BGB wrote:

> the advantage of the GUI based option though is that usually a person
> can click on things faster than they can type things.
> 
> this is mostly an issue of having longish paths to 'cd' through, making
> getting to the desired directory take a little longer (meaning a higher
> initial cost).
> 
> 
> this means that navigating to a directory, or moving between
> directories, can be done faster and easier in Windows Explorer than in a
> shell.

I fail to see how this is relevant.  With today's version control systems, 
you can run any version control software within any subdirectory of a 
versioned project.  Therefore, navigating a directory tree is a non-issue.

This non-issue becomes even less of an issue when we acknowledge that 
terminal emulators support a number of autocomplete features for some 
decades now.

A file manager is a useful tool, and it simplifies some tasks.  Yet, this 
sort of complain regarding the command line interface (CLI) tends to be 
caused by CLI-phobia instead of actual technical limitations or efficiency 
problems.

 
> but, even then, there would be a secondary annoyance:
> MS configures their compiler via environment variables used in the batch
> file used to open the shell (rather than, say, putting the compiler on
> the default path and using an INI file or similar for config). granted,
> OTOH, it does make MSVC a little easier to auto-configure tools against
> than GCC (which would externally appear to use magic to know its
> settings...).
> 
> the issue here is that an "open shell here" would then not be nearly so
> useful if the intent is to rebuild the project...

Version control systems aren't used to build projects, only to 
manage/inspect the series of changes made to a project on any of its 
development branches.  Rebuilding a project has as much to do with version 
control software as copying files around with Microsoft Explorer.


> as-is, I currently have 3 branches of my VM's interpreter:
> the original / current live version;
> a version which I tried to rewrite to use untagged values, but ran into
> problems I can't yet address (there are still holes in the type-system,
> which is a killer for untagged values);
> another version, which I am in the process of migrating from the
> original tagged pointers, to a new tagged-reference system (where the
> references are always 64-bits), mostly as the prior effort ran into a
> wall (64-bit tagged references allow unboxed int/float/double on 32-bit
> targets, although sadly, not an unboxed 64-bit long).
> 
> 
> but, how am I managing these branches:
> well, via copies of the directory tree.
> 
> if this new branch gets written and working, it may then be substituted
> in, in place of the original.

Version control systems were developed specifically with that scenario in 
mind, and that's precisely how they are used.  For example, take the KDE 
project and how they've been using subversion:

http://techbase.kde.org/Getting_Started/Sources/Subversion#The_KDE_repository_structure



>> Development branches are useful even in single-developer projects.  They
>> let you have multiple development branches which can be easily merged and
>> forked.  The best part of it is that versioned history can be kept
>> between merges.
>>
> 
> yes, but this can also be done (more or less) via copies, and is "part
> of the process".

It can be done, but it represents the hard way of doing this, which is also 
error-prone, needlessly time-consuming and needlessly complex.

If you prefer, say, juggling an ungodly number of different tars of a 
directory tree, following different naming schemes whose meaning may even be 
forgotten somewhere in the future, then you are free to do so.  Yet, there 
are far better ways of doing that and more, which are also far simpler as 
well as more robust, resilient and efficient.



Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2710

BGB wrote:

> you can also transfer things using, say, FTP, or network shares (if on a
> LAN). (granted, yes, a person needs an FTP server for the FTP route).
> 
> an advantage of FTP is that (at least via Windows Explorer) it also
> supports copy/paste and drag-and-drop (of both files and folders).

If you really want to, you can use a version control system to manage your 
project tree locally, and then use FTP to stash the project tree somewhere 
else, including the version control data.  For example, Mercurial stores all 
project info in ${Project}/.hg, ${Project} being the project tree's root 
directory.  Git works in an identical manner, storing all info in 
${Project}/.git.  So, if you transfer these directories then you also 
transfer all versioned control info.

Nevertheless, pretty much any version control system abstracts away all this 
low-end janitorial stuff.  Once you've managed to set up a remove 
repository, the only thing that you need to do to save everything in a 
remote server somewhere in the world, including versioned data, is to call 
the relevant version control command.  With both Git, it only takes the 
following command:

git push

To update your project tree, you only need to run the following command:

git pull

No need to remember URLs, explicitly open any connection to any server, 
fiddle with naming versions, or managing these versions in any document 
tree.  Let the version control system deal with that.

Essentially, version control systems were developed by people who had to do 
all this janitorial stuff the hard way but were fed up with its repetitive 
nature.  Therefore, it is expected that these tools handle all these tasks, 
and handle it well.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2713

On 1/2/2013 5:58 AM, Rui Maciel wrote:
> BGB wrote:
>
>> you can also transfer things using, say, FTP, or network shares (if on a
>> LAN). (granted, yes, a person needs an FTP server for the FTP route).
>>
>> an advantage of FTP is that (at least via Windows Explorer) it also
>> supports copy/paste and drag-and-drop (of both files and folders).
>
> If you really want to, you can use a version control system to manage your
> project tree locally, and then use FTP to stash the project tree somewhere
> else, including the version control data.  For example, Mercurial stores all
> project info in ${Project}/.hg, ${Project} being the project tree's root
> directory.  Git works in an identical manner, storing all info in
> ${Project}/.git.  So, if you transfer these directories then you also
> transfer all versioned control info.
>
> Nevertheless, pretty much any version control system abstracts away all this
> low-end janitorial stuff.  Once you've managed to set up a remove
> repository, the only thing that you need to do to save everything in a
> remote server somewhere in the world, including versioned data, is to call
> the relevant version control command.  With both Git, it only takes the
> following command:
>
> git push
>
> To update your project tree, you only need to run the following command:
>
> git pull
>
> No need to remember URLs, explicitly open any connection to any server,
> fiddle with naming versions, or managing these versions in any document
> tree.  Let the version control system deal with that.
>
> Essentially, version control systems were developed by people who had to do
> all this janitorial stuff the hard way but were fed up with its repetitive
> nature.  Therefore, it is expected that these tools handle all these tasks,
> and handle it well.
>

at least with WinXP, I remember being able to do "Map network drive" 
with FTP servers.


annoyingly, I don't seem able to do this with Windows 7, which seems to 
only like shared-folders, and seemingly then, only those shared by other 
Windows 7 computers (it can't seem to access WinXP shared folders for 
some reason, just gives some sort of domain log-in box thingy and 
refuses to go any further...). (IIRC, it still worked for Vista, apart 
from Vista seemingly always defaulting to MSHOME for the workgroup 
rather than WORKGROUP)


hence, sadly, for these uses, FTP ended up replacing the use of shared 
folders...

because, at least FTP still works, even if I can't map it as a network 
drive for whatever reason.

the main difference this makes is mostly that it makes one unable to 
directly open edit files on an FTP server, but have to have a local copy 
to edit stuff.


or such...

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.programming

csiph-web