Searching \ for '[EE] Why I do not use version control (was: New AV' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=new
Search entire site for: 'Why I do not use version control (was: New AV'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Why I do not use version control (was: New AV'
2011\03\03@091446 by William Couture

face picon face
On Thu, Mar 3, 2011 at 7:28 AM, Chris McSweeny <spam_OUTcpmcsweenyTakeThisOuTspamgmail.com> wrote:
> On Thu, Mar 3, 2011 at 9:38 AM, Jesse Lackey <.....jsl-mlKILLspamspam@spam@celestialaudio.com> wrote:
>> If you are developing ... with
>> Subversion/CVS ...
>> This is not the majority of microcontroller development that I do or am
>> involved in, in any way.
>
> So why don't you use any version control? I use Subversion for even my
> hack projects.

While I have worked at companies that used it, I have personally never used
it, and will never encourage any company that I work for to use it.

Why?

Because it can leave you with irretrievable source code.

The company I work for now used a source control system in it's "early
days".  Problem is, the executable was lost over the years.  And the software
vendor disappeared.

So, we have "source files" that were some source, plus internal links in an
unidentified format.  Guess what... I can not figure out what the actual
source is.  Nor can anyone else.  And all the "sandboxes" are long gone.

As a result, the source to several products has been lost.  Some we had to
let die, others we had to re-write from scratch.

If you *MUST* use a source control system, *KEEP A COPY OF ALL
RELEASED VERSIONS OUTSIDE THE SOURCE CONTROL SYSTEM*.

What I do personally is to make a .ZIP file every day of the project I'm
working on, source and build files.  Then copy it to a network server.
This lets me back up to any point I desire, and I'm also safe in case my
work computer dies suddenly.

And, yes, this can create a problem for work groups where several
people are working on the same project.  I can understand the
need for a source control system in such cases, but I have to reiterate
the need for keeping copies of all source outside the source control
system.

Bill

-- Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2011\03\03@094417 by Tamas Rudnai

face picon face
CVS format is pretty easy to understand plus that is open source, so you can
even have the version control system in sources if you want it. You can
setup the server of your own or just use it locally (so you are not
dependent on 3rd party).

Few reasons why a source control is better than ZIPs:

1. You can have a server, not only a local copy of archive files
2. You can collaborate -- so many developer can work on the same project,
you can merge changes fairly easily etc
3. You can create labels and branches, which helps a lot to maintain
different versions of your software, yet still able to patch them with
bugfixes or improvements (think as you create a new device and you need to
customize the firmware for each)
4. You can find these patches and other changes easier (if you maintain the
comments etc correctly)
5. You can leave bugfixes in a temporary branch till you code review and QA
done -- that makes the review faster as the reviewer can see the change
immediately, which source fie is affected etc, and if failed the reviewer
simply just do not merge it to the live code branch.
6. A good source control system only stores changes instead of the entire
source file -- saving you up spaces

Tamas


On Thu, Mar 3, 2011 at 2:14 PM, William Couture <bcouturespamKILLspamgmail.com> wrote:

{Quote hidden}

>

2011\03\03@095040 by Michael Watterson

face picon face
On 03/03/2011 14:14, William Couture wrote:
> And, yes, this can create a problem for work groups where several
> people are working on the same project.  I can understand the
> need for a source control system in such cases, but I have to reiterate
> the need for keeping copies of all source outside the source control
> system.
Absolutely

My wife would even want a printout too. I cured her of wanting a fresh set of cards punched.


Source Control systems IMO are purely to manage Collaborative development. They should never really be used for archiving versions and especially not for backup.

if you can have only one person per module, arguably you hardly need them. If you are single person working on something why would you use one?

They are all also rather horrid to use

2011\03\03@095438 by Michael Watterson

face picon face
On 03/03/2011 14:14, William Couture wrote:
> So, we have "source files" that were some source, plus internal links in an
> unidentified format.  Guess what... I can not figure out what the actual
> source is.  Nor can anyone else.  And all the "sandboxes" are long gone.
>

I've found that to be problem for projects (esp C, C++ etc) using complex conditional "make files".

You somehow got all the source (but no other documentation and no make files) and spend a month trying to analyse  how to build it.

(Thinks ... I have exe for x86. I have bin for MIPS, did the ARM version EVER build?)

2011\03\03@095809 by Joe Koberg

flavicon
face
On 2011-03-03 08:14, William Couture wrote:
> On Thu, Mar 3, 2011 at 7:28 AM, Chris McSweeny<cpmcsweenyspamspam_OUTgmail.com>  wrote:
>> On Thu, Mar 3, 2011 at 9:38 AM, Jesse Lackey<@spam@jsl-mlKILLspamspamcelestialaudio.com>  wrote:
>>> If you are developing ... with
>>> Subversion/CVS ...
>>> This is not the majority of microcontroller development that I do or am
>>> involved in, in any way.
>> So why don't you use any version control? I use Subversion for even my
>> hack projects.
> While I have worked at companies that used it, I have personally never used
> it, and will never encourage any company that I work for to use it.
>
> Why?
>
> Because it can leave you with irretrievable source code.
>
> The company I work for now used a source control system in it's "early
> days".  Problem is, the executable was lost over the years.  And the software
> vendor disappeared.
>

Getting bitten by proprietary vendor file formats is common.  Try to find something to open old WordPerfect documents with some accuracy!

This is one of the biggest reasons to choose open source software and software that uses open file formats to me.  The vendor can't disappear.

Once that hurdle is removed (there is no reason for anyone to decide to use proprietary source control), the advantages of version control are numerous.


> What I do personally is to make a .ZIP file every day of the project I'm
> working on, source and build files.  Then copy it to a network server.
> This lets me back up to any point I desire, and I'm also safe in case my
> work computer dies suddenly.
>

This is probably sound no matter what, but notice you have chosen an open-standard archive format for your backup.  SVN, CVS, Git, etc... are also open-standard archive formats with many users.



Joe Kober

2011\03\03@095851 by mcd

flavicon
face
William Couture wrote:
> While I have worked at companies that used it, I have personally never
> used it, and will never encourage any company that I work for to use
> it.
>
> Why?
>
> Because it can leave you with irretrievable source code.

This is a closed source problem, not a version control problem, and it
goes way beyond version control.  The same is true of almost any older,
closed-source application.

And in most of the older version control systems, the code can be
retrieved with a little scripting even if the version control program is
lacking.

Being an old fogey and having been through more platforms than I can
count, I try pretty hard to stick to applications that are
platform-agnostic.  That old code especially is valuable.  Although not
every day, from time to time I find myself grabbing code from a project
several platforms ago, rather than writing new.

For ages I used RCS, which is quite old, but has the feature of being
available on practically every platform known to man.  I have a few old
repos that migrated from DOS to Windows to OS/2 to VMS back to Windows to
Linux, all with no conversion.

Personally, I am getting to really like git, which doesn't have this
feature of an almost human-readable repository, but the convenience is
terrific, and I can mirror my repos on gitorious or github and have
convenient offsite backup as well.  Pity MPLAB doesn't directly interface
with git, but it's no real biggie to update from the remote repo manually.

--McD

2011\03\03@100327 by Olin Lathrop

face picon face
Michael Watterson wrote:
> if you can have only one person per module, arguably you hardly need
> them. If you are single person working on something why would you use
> one?

To get the nice documented history of each module, see which versions of
each file were used to produce what versions of executables when, etc.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\03@101739 by Walter Banks

picon face


William Couture wrote:

> What I do personally is to make a .ZIP file every day of the project I'm
> working on, source and build files.  Then copy it to a network server.
> This lets me back up to any point I desire, and I'm also safe in case my
> work computer dies suddenly.

This is what we have been doing as well. We have used backup systems
in the past but the wrong time to test a back up system restore is when you
need it. ZIP files are used every day and there is a confidence that they
will work even when development platforms change into the future.

One other thing that we do is when we do a release (anytime we send a
tool outside the office) we zip the development sources, libraries,  and
released executable and save separately from the development platform(s) .
These have proved invaluable later in supporting  customers with frozen
branch support.

Regards,


w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com





2011\03\03@102824 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On
Behalf
> Of Michael Watterson
> Sent: 03 March 2011 14:50
> To: Microcontroller discussion list - Public.
> Subject: Re: [EE] Why I do not use version control (was: New AVR
Studio 5)
>
> On 03/03/2011 14:14, William Couture wrote:
> > And, yes, this can create a problem for work groups where several
> > people are working on the same project.  I can understand the
> > need for a source control system in such cases, but I have to
reiterate
> > the need for keeping copies of all source outside the source control
> > system.
> Absolutely
>
> My wife would even want a printout too. I cured her of wanting a fresh
> set of cards punched.
>
>
> Source Control systems IMO are purely to manage Collaborative
> development. They should never really be used for archiving versions
and
> especially not for backup.
>
They go way beyond collaborative development; I use source control for
all my work, even personal stuff.  With a source control system you have
a permanent, unchangeable picture of the source at various stages
through the development and a file difference operation is a couple of
clicks away between different versions of each file. Zip archives simply
don't give you this security and convenience.


> if you can have only one person per module, arguably you hardly need
> them. If you are single person working on something why would you use
one?
>
> They are all also rather horrid to use.

I think that is typical of someone who hasn't used source control much.
I didn't like using it either (and tbh I still don't like learning new
tools much), but as you get comfortable with using these systems you
will see what a useful and important part of the development process
they are.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\03\03@103949 by Michael Watterson

face picon face
On 03/03/2011 15:03, Olin Lathrop wrote:
> Michael Watterson wrote:
>> if you can have only one person per module, arguably you hardly need
>> them. If you are single person working on something why would you use
>> one?
> To get the nice documented history of each module, see which versions of
> each file were used to produce what versions of executables when, etc.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
The human has to create that anyway, properly, Source control system or not. A decent system will help track, agreed

2011\03\03@104213 by Gordon

flavicon
face
On Thu, Mar 3, 2011 at 3:03 PM, Olin Lathrop <spamBeGoneolin_piclistspamBeGonespamembedinc.com> wrote:
> Michael Watterson wrote:
>> if you can have only one person per module, arguably you hardly need
>> them. If you are single person working on something why would you use
>> one?

Its good for looking at regressions, If i've been in throws of code
Hacking and broken something that previously worked, being able to
diff against a previous day to see what changed can speed up tracking
down regressions.

It also allows me to work from multiple machines / switch between my
laptop and desktop as required.

G :-

2011\03\03@104511 by Olin Lathrop

face picon face
Michael Watterson wrote:
>> To get the nice documented history of each module, see which
>> versions of each file were used to produce what versions of
>> executables when, etc.
>
> The human has to create that anyway, properly, Source control system
> or not.

Not really.  Right now we describe releases in a separate document, but
there isn't a good mechanism for the per-module tracking that a good source
code control system provides.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\03@104700 by mcd

flavicon
face
Olin Lathrop wrote:

> To get the nice documented history of each module, see which versions
> of each file were used to produce what versions of executables when,
> etc.

And to know what was changed for what purpose without cluttering up the
code with comments.  For example:

https://github.com/jjmcd/Elmer160/blame/master/LCDlib/LCDinsc.asm

and you can see what commit is "blamed" for a particular line.

If you wonder what other files were affected by that same commit, click
on, for example, eedde787 (the "All code in named section" commit happens
to have affected a number of source files) and you will see all the files
touched by that commit, and below that list the differences in each file.

When you go back to grab some old code, or even when you are pulled awy
from a project for a while, it can be hard to remember these things.

--McD

2011\03\03@104823 by Michael Watterson

face picon face
On 03/03/2011 15:28, Michael Rigby-Jones wrote:
>> if you can have only one person per module, arguably you hardly need
>> >  them. If you are single person working on something why would you use
> one?
>> >  
>> >  They are all also rather horrid to use.
> I think that is typical of someone who hasn't used source control much.
> I didn't like using it either (and tbh I still don't like learning new
> tools much), but as you get comfortable with using these systems you
> will see what a useful and important part of the development process
> they are.

I've used them plenty for years.

I don't trust software more because it's Open Source.
I trust me with my data more than I trust Google's Cloudy Source offering.
I'm none too fond of client ends that integrate into my desktop as Programming not always a full time activity. It might be for 6 months or a year or two and then not at all.

If it's a large project I agree Source Control system is a help. You still need separate backups outside of any Source Control System and properly documented. Probably even with a installable copy of all the tools needed. Ultimately even a backup copy of Operating systems for tools or targets.

it all depends.

2011\03\03@105857 by Isaac Marino Bavaresco

flavicon
face
Em 3/3/2011 11:44, Tamas Rudnai escreveu:
{Quote hidden}

I completely agree, there is no reason for not using a VCS.
I work completely alone and use Subversion for all my projects.

Isaac

2011\03\03@110248 by Isaac Marino Bavaresco

flavicon
face
Em 3/3/2011 11:50, Michael Watterson escreveu:
{Quote hidden}

The tools that Subversion offers are great for comparing versions and
finding bugs, specially regressions.
And it is very easy to backup your entire repository, and thus all the
versions and revisions of your projects at once.

Isaac

2011\03\03@110530 by Tamas Rudnai

face picon face
On Thu, Mar 3, 2011 at 3:48 PM, Michael Watterson <TakeThisOuTmikeEraseMEspamspam_OUTradioway.org> wrote:

> I don't trust software more because it's Open Source.
>

At least the format they are using is not closed -- but yeah, quality of the
code could be worse than a proprietary code as those might just developed
someone next door to you over weekends. (It also could be supported by a
large organisation, it depends)


> If it's a large project I agree Source Control system is a help. You
> still need separate backups outside of any Source Control System and
> properly documented. Probably even with a installable copy of all the
> tools needed. Ultimately even a backup copy of Operating systems for
> tools or targets.
>

Backup, Archive and Source Control are 3 different things in my opinion.
Backup is to be able to continue work from a certain stage rather than
loosing something. Archive is to put the code in a safe place just to be in
record -- God knows, maybe you need it sometime 10 years later. Source
Control is to control your sources, versions, bugfixes, patches, to
collaborate with other developers etc.

Normally you backup your repository of data files in your source control
system + archive sources on a CD/DVD or other (more) reliable media and keep
it in a fire proof safe etc.

Tamas




>
> it all depends.
>
>
>

2011\03\03@110616 by Isaac Marino Bavaresco

flavicon
face
Em 3/3/2011 11:54, Michael Watterson escreveu:
> On 03/03/2011 14:14, William Couture wrote:
>> So, we have "source files" that were some source, plus internal links in an
>> unidentified format.  Guess what... I can not figure out what the actual
>> source is.  Nor can anyone else.  And all the "sandboxes" are long gone.
>>
> I've found that to be problem for projects (esp C, C++ etc) using
> complex conditional "make files".
>
> You somehow got all the source (but no other documentation and no make
> files) and spend a month trying to analyse  how to build it.


The make-files, documentation and other support files may (and should)
be versioned also.


> (Thinks ... I have exe for x86. I have bin for MIPS, did the ARM version
> EVER build?)


I don't see the point. You may keep branches for each platform, or
preferably keep them all together with conditional compilation.

Isaac

2011\03\03@110922 by Isaac Marino Bavaresco

flavicon
face
Em 3/3/2011 12:03, Olin Lathrop escreveu:
> Michael Watterson wrote:
>> if you can have only one person per module, arguably you hardly need
>> them. If you are single person working on something why would you use
>> one?
> To get the nice documented history of each module, see which versions of
> each file were used to produce what versions of executables when, etc.


I keep even the HEX files of my projects in the repository, so I don't
need to recompile them if I need an old version.

Isaac

2011\03\03@112337 by Michael Watterson

face picon face
On 03/03/2011 16:06, Isaac Marino Bavaresco wrote:
> The make-files, documentation and other support files may (and should)
> be versioned also.
Of course. But seemingly some projects don't think of it

2011\03\03@112718 by Mark Rages

face picon face
On Thu, Mar 3, 2011 at 10:09 AM, Isaac Marino Bavaresco
<RemoveMEisaacbavarescospamTakeThisOuTyahoo.com.br> wrote:
> Em 3/3/2011 12:03, Olin Lathrop escreveu:
>> Michael Watterson wrote:
>>> if you can have only one person per module, arguably you hardly need
>>> them. If you are single person working on something why would you use
>>> one?
>> To get the nice documented history of each module, see which versions of
>> each file were used to produce what versions of executables when, etc.
>
>
> I keep even the HEX files of my projects in the repository, so I don't
> need to recompile them if I need an old version.
>
> Isaac
>

There's another advantage (besides convenience) of keeping old
binaries around:  If you need to go back to modify a project, you can
compare newly-created binaries with the original ones, to make sure
the tools are working the same.

I use subversion + trac for all projects, personal and professional.
It helps debugging things like "this firmware was working this
morning, now it's broken... what changed?" as well as being an
organizational tool.

I highly recommend Trac to all you subversion users.  It lets you look
at the repository through a web browser, with nice colored diffs and
syntax-highlighted source browsing.   It's easier than learning all
the rarely-used options to the command-line tools.

Regards,
Mark
markrages@gmail
-- Mark Rages, Engineer
Midwest Telecine LLC
markragesEraseMEspam.....midwesttelecine.co

2011\03\03@124036 by Manu Abraham

picon face
On Thu, Mar 3, 2011 at 8:20 PM, Michael Watterson <EraseMEmikespamradioway.org> wrote:
>
> Source Control systems IMO are purely to manage Collaborative
> development. They should never really be used for archiving versions and
> especially not for backup.


This isn't true.

Look at this scenario:

- I hacked away on a 1000 lines of code, it didn't work.
- after struggling, with lot of thoughts and help from online
communities, phew I got my basic idea to work.
- I was very happy, this made me over zealous and spent the next 2
weeks at hacking in new features, ideas and concepts.
- eventually, as expected everything broke down, I couldn't even trace
back to my original state.
- with lot of frustration, I searched for those bits and pieces what I
had originally.

* Phew, I got back to my old state. But what happened to my
inspirations, ideas and thoughts ?


Now, look at this scenario:

- I hacked away some crap. using a SCM I committed it to the repository
- After some efforts, I got things working. I committed it with a Tag
line, "this version works"
- I became over zealous, hacked away on tons of code, what was once
working broke completely.
- I looked at my commit logs, I checked out the version that was
working. Phew, that hardly took a minute.

Now, I can keep trying to identify the problems in the code that
checked in after a last working commit.

Now, I have breathing space.


Now, lets look at another scenario:

- I hacked away on tons of code after having working situations, each
time making a separate archive for backup/storage.

- I got into some other new work. and return back after almost 6
months/ or a year and I have lost track of what I did.

Now, in the situation that I have been using a SCM/VCS, I can just
look up at my commit logs (of course I had to commit each of my
changes with a meaningful entry); Hey, all that old memories flash
down my mind like a movie.

Phew, saved again ...


You can maintain a 1:1 relation between builds and files only when you
are dealing with small projects or fewer projects. When your hands are
there in so many places, you really need to keep track of what you are
doing.


> if you can have only one person per module, arguably you hardly need
> them. If you are single person working on something why would you use one?
>
> They are all also rather horrid to use.


have you tried mercurial ?
http://mercurial.selenic.com/

generally SCM's are horrid to use, why because they are tedious to
setup and too many commands to be remembered.

mercurial is simple to use, require no servers (unless you want to
host them for public reasons)

I have a few repositories, VCS really made my life easier ..
http://jusst.de/hg/


Man

2011\03\03@144429 by Peter Loron

flavicon
face
On 03/03/2011 07:00 AM, RemoveMEmcdEraseMEspamEraseMEis-sixsigma.com wrote:
{Quote hidden}

I cannot imagine doing software development (embedded or not) without version control. It has saved my bacon numerous times, as well as making it very easy to keep track of what changed where and making it safer to work on breaking changes, etc.

Yes, you can replicate some of that using manual copies of files and zip archives, but why? VCS is designed to handle those tasks elegantly. An investment in learning the tool has paid huge dividends for me over the years.

I heartily second the recommendation for git. Awesome tool.

-Pet

2011\03\03@150523 by M.L.

flavicon
face
On Thu, Mar 3, 2011 at 2:44 PM, Peter Loron <RemoveMEpeterlspam_OUTspamKILLspamstandingwave.org> wrote:

> I cannot imagine doing software development (embedded or not) without
> version control. It has saved my bacon numerous times, as well as making
> it very easy to keep track of what changed where and making it safer to
> work on breaking changes, etc.
>
> Yes, you can replicate some of that using manual copies of files and zip
> archives, but why? VCS is designed to handle those tasks elegantly. An
> investment in learning the tool has paid huge dividends for me over the
> years.
>
> I heartily second the recommendation for git. Awesome tool.
>
> -Pete


Most of us are writing code for someone else, be they a "boss" or
customer. If someone says: "what exactly did you change?"
and you can't answer the question as a matter of fact, you might look
a little silly. I worked on a dsPIC project with 3 other developers
concurrently, and there was no way it would have worked if we weren't
using some revision control. It just happens to be a lot easier when
there is software that does the diffs and tracking for you. I use
Mercurial, I like it because it's distributed. There is no master
repository as a limitation of the revision control.

In the example I mentioned, we used KilnHG to serve the repository to
all of the developers. It graphically shows forks, lineage, merges,
all history, etc. Being able to go back and see exactly which lines of
code changed has helped me be more productive. I can also see exactly
what OTHER people are doing to code that might affect what I'm working
on.

I also happen to touch about 5 different projects in a month, and
usually I'm working alone on the code. I can't remember every detail
about every code base, regardless of how good my memory (or
documentation) is. Seeing old commit messages and diffs in Tortoise-HG
refreshes my memory. It took about 2 hours to learn how to use
Mercurial and it has saved me many times that.

-- Martin K

2011\03\03@162635 by Manu Abraham

picon face
On Fri, Mar 4, 2011 at 1:34 AM, M.L. <RemoveMEmTakeThisOuTspamspamlkeng.net> wrote:
{Quote hidden}

Actually, for newbies to get started you don't even need to know all
the mercurial commands

A quick n' dirty way to get started would be as simple as 5 commands

- Creating a repository

hg init: create a new repo
hg addremove: addremove files in one go

- Working on the repository

hg clone: if you want to clone another repository
hg commit: commit your changes
hg log: view the commit logs

I don't think a VCS usage can be any simpler to get started.

and you are started. I have used CVS, Mercurial and Git. Git is more
powerful and feature rich, but can be a bit overwhelming for a newbie
who has never used a VCS before

2011\03\03@180245 by Chris McSweeny

picon face
On Thu, Mar 3, 2011 at 4:26 PM, Mark Rages <RemoveMEmarkragesKILLspamspamgmail.com> wrote:
> I highly recommend Trac to all you subversion users.  It lets you look
> at the repository through a web browser, with nice colored diffs and
> syntax-highlighted source browsing.   It's easier than learning all
> the rarely-used options to the command-line tools.

Interesting -  not come across that. However I doubt I'll switch, as
an alternative for Windows users is TortoiseSVN - integrates into
Windows explorer, and is what I use. You never have to know any
subversion command line stuff to use it, and the only thing vaguely
difficult is creating your initial repository - after that it's all
point and click.

I'm assuming those who think using version control sw is difficult
have never tried something as straightforward as TortoiseSVN, or
presumably Trac. Far, far easier than archiving using zip - I used to
do that, but it doesn't provide you with all the advantages proper vc
sw does.

I mean a lot of my home projects consist of a single small .asm file,
but they still go under version control so that I can track changes
and revert if necessary - once you've got TortoiseSVN setup it's just
so trivial to add a new project.

Chris

2011\03\03@191432 by Mark Rages

face picon face
On Thu, Mar 3, 2011 at 5:02 PM, Chris McSweeny <cpmcsweenySTOPspamspamspam_OUTgmail.com> wrote:
> On Thu, Mar 3, 2011 at 4:26 PM, Mark Rages <spamBeGonemarkragesSTOPspamspamEraseMEgmail.com> wrote:
>> I highly recommend Trac to all you subversion users.  It lets you look
>> at the repository through a web browser, with nice colored diffs and
>> syntax-highlighted source browsing.   It's easier than learning all
>> the rarely-used options to the command-line tools.
>
> Interesting -  not come across that. However I doubt I'll switch, as
> an alternative for Windows users is TortoiseSVN - integrates into
> Windows explorer, and is what I use. You never have to know any
> subversion command line stuff to use it, and the only thing vaguely
> difficult is creating your initial repository - after that it's all
> point and click.
>

Trac is a view-only SVN client and Wiki.   It is not a substitute for
TortiseSVN or the svn command-line or whatever, but is an alternative
way to query the repository and write documentation that references
the repository.

Personally, I find TortiseSVN unpleasant to use.  I am not sure how to
do things like moves, copies, and merges with it.  And it makes it too
easy to check in intermediate / generated files accidentally.

Regards,
Mark
markrages@gmail
-- Mark Rages, Engineer
Midwest Telecine LLC
KILLspammarkragesspamBeGonespammidwesttelecine.com

2011\03\03@214508 by mcd

flavicon
face
A comment on version control systems, especially git ...

Most version control systems are descendants of the ancient RCS. CVS, SVN,
Mercurial, and on and on are all pretty much attempts to make RCS function
in a collaborative environment.

A few years ago, Linus saw some issues with these old control systems,
especially speed, and decided to do a new, from-scratch VCS which he
called git.  Today, most new projects in the FOSS world use git and many
existing projects have converted or are converting.  The Linux kernel
project, of course, was the first.

Four or five years ago virtually every open source project used CVS or
SVN, mostly SVN.  Now practically everyone uses git.

git is way faster than those older systems, although unless your project
is absolutely huge you can't see the difference.  But if your project IS
huge, the difference is dramatic, roughly an order of magnitude speed
difference for very large operations.

But it doesn't come free.  If you are used to one of the older systems it
can be really hard to get your head around git.

In most of the older systems the repository consists of the files with
patch instructions to get to the earlier versions, so even if you didn't
have the software it is possible, if tedious, to recover your files.  In
git, everything is a hash so the files in the repository make no sense at
all.

In most of the older systems, versions get named something sensible by
default, like 1.1, 1.1.2, etc.  In git everything, and I mean everything,
is named with a SHA1 hash.

But the reality is you almost never need to refer to something by a
version number unless it is one you assigned anyway (which you can do with
any of the systems), and mostly you either do default commits or use the
GUI, so this isn't as big a deal as it sounds.

If you are an SVN or CVS user, it is really really hard to get the hang of
git.  But once you do, going back to SVN is like having your fingernails
pulled out.

All of the big hitters, CVS, SVN, RCS, git, integrate with pretty much
every IDE, except, of course, Microsoft who integrates with SourceSafe. SVN, git and I assume CVS, but probably RCS, all have web interfaces as
well which can be darned handy for browsing a large number of
repositories.

If you still have an MS-DOS box you are probably stuck with RCS.

--McD

2011\03\04@003006 by William \Chops\ Westfield

face picon face

On Mar 3, 2011, at 6:54 AM, Michael Watterson wrote:

> You somehow got all the source (but no other documentation and no make
> files) and spend a month trying to analyse  how to build it.

I was thinking recently that there were certain instances of  proprietary commercial software where releasing the source to open  source could probably set back open source for YEARS trying to figure  out how to make them actually build in any useful form...

BillW

2011\03\04@033130 by Michael Watterson

face picon face
On 03/03/2011 23:02, Chris McSweeny wrote:
> Interesting -  not come across that. However I doubt I'll switch, as
> an alternative for Windows users is TortoiseSVN - integrates into
> Windows explorer, and is what I use. You never have to know any
> subversion command line stuff to use it, and the only thing vaguely
> difficult is creating your initial repository - after that it's all
> point and click.
I use Rapid SVN for googlecode svn

I specifically DON'T EVER want an source control system, or anything else integrated to Explorer.

2011\03\04@033522 by Michael Watterson

face picon face
On 04/03/2011 05:28, William "Chops" Westfield wrote:
> On Mar 3, 2011, at 6:54 AM, Michael Watterson wrote:
>
>> >  You somehow got all the source (but no other documentation and no make
>> >  files) and spend a month trying to analyse  how to build it.
> I was thinking recently that there were certain instances of
> proprietary commercial software where releasing the source to open
> source could probably set back open source for YEARS trying to figure
> out how to make them actually build in any useful form...
>
> BillW
>
When Symbian itself was originally released as OS, you could not build it. Unless you already had access to building it and the tools previously

2011\03\04@034619 by Chris McSweeny

picon face
On Fri, Mar 4, 2011 at 8:31 AM, Michael Watterson <EraseMEmikespamEraseMEradioway.org> wrote:
> On 03/03/2011 23:02, Chris McSweeny wrote:
>> Interesting -  not come across that. However I doubt I'll switch, as
>> an alternative for Windows users is TortoiseSVN - integrates into
>> Windows explorer, and is what I use. You never have to know any
>> subversion command line stuff to use it, and the only thing vaguely
>> difficult is creating your initial repository - after that it's all
>> point and click.
> I use Rapid SVN for googlecode svn
>
> I specifically DON'T EVER want an source control system, or anything
> else integrated to Explorer.

You're sounding like a bit of a zealot. I fail to see what is wrong
with Explorer.

Chria

2011\03\04@041035 by Manu Abraham

picon face
On Fri, Mar 4, 2011 at 2:16 PM, Chris McSweeny <@spam@cpmcsweeny@spam@spamspam_OUTgmail.com> wrote:
> On Fri, Mar 4, 2011 at 8:31 AM, Michael Watterson <spamBeGonemikespamKILLspamradioway.org> wrote:
>> On 03/03/2011 23:02, Chris McSweeny wrote:
>>> Interesting -  not come across that. However I doubt I'll switch, as
>>> an alternative for Windows users is TortoiseSVN - integrates into
>>> Windows explorer, and is what I use. You never have to know any
>>> subversion command line stuff to use it, and the only thing vaguely
>>> difficult is creating your initial repository - after that it's all
>>> point and click.
>> I use Rapid SVN for googlecode svn
>>
>> I specifically DON'T EVER want an source control system, or anything
>> else integrated to Explorer.
>
> You're sounding like a bit of a zealot. I fail to see what is wrong
> with Explorer.


It's not that anything is wrong with Explorer. Every task has it's
place. Context menus do look nice, but the accidents that you can make
with it are also easy. To put it short:

"When you make things easier, the accidents also do come easier."

eg: my mouse went crazy, or that something went wrong, or I was too
dizzy .. With context menus things can go wrong also easily.

eg: one person whom I know, after getting intoxicated, played with the
context menus on his computer on a Windows desktop. Eventually and
accidentally, it set the display upside down on his Intel Graphics
accelerator. He went to sleep after getting tied of the entire world
upside down. Next day only he realize that, it was not his
intoxication that made things look upside down... He was off
scrambling asking people how to get his original desktop state.
Initially he tried placing the monitor upside down for the urgent work
he had to do...

So much for context menus..

That said, they are useful too, in a realistic world.

2011\03\04@064311 by Michael Watterson

face picon face
On 04/03/2011 08:46, Chris McSweeny wrote:
> You're sounding like a bit of a zealot. I fail to see what is wrong
> with Explorer.
>
Nothing, now that I have Tortoise removed.

even so for serious amount of files xcopy is needed. Explorer is perfect for browsing and copy or move of a few files.

I have no problem with either Explorer Desktop or Explorer File Browser/Manager. At least on a decent Screen (some smaller Netbooks are bit low resolution in total pixels, not dpi, for Windows). I've been using a 1600 x 1200 LCD since early 2002. Occasionally I use 1400 x 1050 LCD and 1920x 1080 or 1600x1200 CRTs.

Programming is not a full time occupation for me. I don't want to have its tools cluttering the place when I'm not doing it. Similarly I got rid of MS Services for Unix and Cygwin. If I need Linux I use a dedicated Linux laptop, or multiboot or a VM in VMware (last is poor when developing Device Drivers, so not used it much). I did have an X-Server that ran each X app in a Windows Window on Explorer Desktop. That was nice integration. For various reasons Windows + Explorer desktop can do that better than the reverse of running Windows apps via Wine on KDE or Gnome.

If your job is 100% programming maybe full shell/Explorer integration is a good idea.

2011\03\04@072937 by M.L.

flavicon
face
On Fri, Mar 4, 2011 at 6:42 AM, Michael Watterson <.....mikespam_OUTspamradioway.org> wrote:
> On 04/03/2011 08:46, Chris McSweeny wrote:
>> You're sounding like a bit of a zealot. I fail to see what is wrong
>> with Explorer.
>>
> Nothing, now that I have Tortoise removed.
>

Everybody has their preferences. Why don't we just start a Mac vs 'PC'
argument? Everyone knows that discussion already, so we won't have to
do any research, and the outcome will be exactly the same.

-- Martin K

2011\03\04@075551 by Isaac Marino Bavaresco

flavicon
face
Em 4/3/2011 02:28, William "Chops" Westfield escreveu:
> On Mar 3, 2011, at 6:54 AM, Michael Watterson wrote:
>
>> You somehow got all the source (but no other documentation and no make
>> files) and spend a month trying to analyse  how to build it.
> I was thinking recently that there were certain instances of  
> proprietary commercial software where releasing the source to open  
> source could probably set back open source for YEARS trying to figure  
> out how to make them actually build in any useful form...
>
> BillW


The repository must contain *everything* necessary to build the final
product, except the build tools themselves.
I always keep back-ups of the installers for every version of the build
tools I ever used and keep a note on the source files saying what build
tools and versions were used.

Isaac

2011\03\04@081653 by Chris McSweeny

picon face
On Fri, Mar 4, 2011 at 11:42 AM, Michael Watterson <TakeThisOuTmike.....spamTakeThisOuTradioway.org> wrote:
> On 04/03/2011 08:46, Chris McSweeny wrote:
>> You're sounding like a bit of a zealot. I fail to see what is wrong
>> with Explorer.
>>

> Programming is not a full time occupation for me. I don't want to have
> its tools cluttering the place when I'm not doing it.

Ah - now you're sounding like a zealot who hasn't actually tried what
it is you don't like. Most users would never even know TSVN was
installed. If you right click on a file you'll get the extra options
in the menu, but they're incredibly easy to ignore.

Chri

2011\03\04@085203 by Isaac Marino Bavaresco

flavicon
face
Em 4/3/2011 10:16, Chris McSweeny escreveu:
> On Fri, Mar 4, 2011 at 11:42 AM, Michael Watterson <TakeThisOuTmikeKILLspamspamspamradioway.org> wrote:
>> On 04/03/2011 08:46, Chris McSweeny wrote:
>>> You're sounding like a bit of a zealot. I fail to see what is wrong
>>> with Explorer.
>>>
>> Programming is not a full time occupation for me. I don't want to have
>> its tools cluttering the place when I'm not doing it.
> Ah - now you're sounding like a zealot who hasn't actually tried what
> it is you don't like. Most users would never even know TSVN was
> installed. If you right click on a file you'll get the extra options
> in the menu, but they're incredibly easy to ignore.
>
> Chris


He could use the original command-line Subversion tools. TortoiseSVN is
just a productivity enhancement tool for GUI, don't need to be installed
at all.
Subversion is command-line zealot compliant.

Isaac

2011\03\04@093056 by Michael Watterson

face picon face
On 04/03/2011 13:16, Chris McSweeny wrote:
> Ah - now you're sounding like a zealot who hasn't actually tried what
> it is you don't like. Most users would never even know TSVN was
> installed. If you right click on a file you'll get the extra options
> in the menu, but they're incredibly easy to ignore.
>
 you sound like someone that hasn't seen my desktop.
already 12 items on Right Click and some have as many on submenu. Already too many.

I gave TSVN a  good workout and changed to Rapid SVN. Suits my needs far better. I agreed that for some other people TSVN might be fine so you are nitpicking.

12 under New -> it got to 20 and I did a clean up. The only thing I want under new are Folder and Shortcut. Other stuff adds itself without asking due to naughty installers written by egotistical programmers.

2011\03\04@093632 by Michael Watterson

face picon face
On 04/03/2011 13:52, Isaac Marino Bavaresco wrote:
> He could use the original command-line Subversion tools. TortoiseSVN is
> just a productivity enhancement tool for GUI, don't need to be installed
> at all.
> Subversion is command-line zealot compliant.
or I can continue with Rapid SVN
In  Netbeans doing Java I use the built in IDE tools to connect to repositories of various kinds, local on our own server and on the Internets

I can't say I liked SourceSafe on VS 6.0

I've recently switched from VB 6.0 to C# on .net 4.0 for "odds and ends" of windows programming, so I may look at version control etc on that. I did 1st use C# in 2003, but didn't stick at it. More like MS J++ than C++ which I've used since 1987 or 1988 perhaps. Before I did C in  1988 or 198

2011\03\04@095148 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesspamRemoveMEmit.edu [RemoveMEpiclist-bouncesspamspamBeGonemit.edu] On
Behalf
> Of Michael Watterson
> Sent: 04 March 2011 14:36
> To: Microcontroller discussion list - Public.
> Subject: Re: [EE] Why I do not use version control (was: New AVR
Studio 5)
>
>
> I can't say I liked SourceSafe on VS 6.0

The first source control system I ever used.  It's rather limited
compared to other systems, but as a single developer I found it
perfectly adequate, and it was beautifully simple to use compared to CVS
etc.  No integration with Explorer etc. is required and it provided
command lines tools you could integrate into makefiles etc.

>
> I've recently switched from VB 6.0 to C# on .net 4.0 for "odds and
ends"
> of windows programming, so I may look at version control etc on that.
I
> did 1st use C# in 2003, but didn't stick at it. More like MS J++ than
> C++ which I've used since 1987 or 1988 perhaps. Before I did C in
1988
> or 1989

See this is a move I really don't want to make.  I use VB6 all the time
to create simple engineering test applications/GUI's etc. and whilst it
certainly has it's limitations, it also has excellent debugging, runs
nicely on older PC's and creates compact executables without a grossly
bloated run time library.  
IME C#/VB.Net development brings older PC's to their knees, the
executables appears to run no faster than VB6, and slower in many cases
and the .Net runtime is an absolute monster.  The debugging is hit and
miss, trying to move the execution point back and forward frequently
results in a crash.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\03\04@111836 by Michael Watterson

face picon face
On 04/03/2011 14:51, Michael Rigby-Jones wrote:
> IME C#/VB.Net development brings older PC's to their knees, the
> executables appears to run no faster than VB6, and slower in many cases
> and the .Net runtime is an absolute monster.  The debugging is hit and
> miss, trying to move the execution point back and forward frequently
> results in a crash.
At the start, it's building native versions from the .net byte code so the visual studio 10  2008 is like treacle

once it's done that in the background it's a bit faster for IDE and application than VB6 on a P4M 1.8GHz, 9 years old.

..Net 4.0 is still very bloated but seems a big improvement on 3.0 which was big bad thing compared to 2.0

IMO though no point to to vb.net, it's not a newer version of VB6. it's VB designed by a C programmer. The c# is better. It's just like VB6 in many ways but with syntax closer to Java. It's not C or C++ for sure.

Teaching Granny to Suck Eggs bit:

The new features of visual design  and how scaling/dock/anchor/margin/padding work are alternately fantastic and horrifying till you figure them out.
Simply reading up on those and doing some micky mouse code to play with GUI / Visual designer is valuable.

VB6 button up and Button down images:
a lot of complicated explanations on web how to (as buttons now only have a background image).

Actually what is VERY simple, even if porting VB6 to c# is have an ImageList.
A button can take an imagelist
make index 0 be button up and index 1 be button down. Text can overlay on the imagelist image, so where in VB you might have had 20 custom images you maybe have 2 or 3 (you can have a mouse over event) and text.

The important thing is not to do stuff the java/vb6/C++ etc way and go off and write a new class to add the "missing" feature, but understand how .net 4.0 Windows forms meant to work and how c# is meant to be used.

2011\03\04@112541 by Neil Cherry

flavicon
face
On 03/03/2011 11:23 AM, Michael Watterson wrote:
> On 03/03/2011 16:06, Isaac Marino Bavaresco wrote:
>> The make-files, documentation and other support files may (and should)
>> be versioned also.
> Of course. But seemingly some projects don't think of it.

Really? I'm not a software developer and that seems so odd to me.
I'd expect to have everything included (including my text notes
so I can better recall things). I want to get a build, type make
(or ant or whatever) and I expect it should compile if I have the
correct developer env. I'm also of the habit of building shell
scripts (I work a lot with Linux) to setup shell envs so they're
not hard coded in my profile. Then everything into the repo. .

-- Linux Home Automation         Neil Cherry       spamBeGonencherry@spam@spamspam_OUTlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummie

2011\03\04@195221 by William \Chops\ Westfield

face picon face

On Mar 4, 2011, at 4:55 AM, Isaac Marino Bavaresco wrote:

> The repository must contain *everything* necessary to build the final
> product, except the build tools themselves.

That "except the build tools themselves" is a huge hole in your  philosophy, and a big part of what I was talking about.  Our "tools"  binary directory contains over 4000 items (including things like  versioned copies of the C compiler for several targets and several  versions.) (and SCV software sucks at binary files.)  God help you if  your makefile uses some feature that you thought was a standard part  of some /usr/bin utility that "the community" decides Must Be Changed.

You can get an unpleasant glimpse of some of the issues if you try to  install open source software of any complexity from the linux  community on a (theoretically) slightly different unix system like a  Mac, FreeBSD, or netBSD system...

BillW

2011\03\04@205929 by Isaac Marino Bavaresco

flavicon
face
Em 4/3/2011 21:51, William "Chops" Westfield escreveu:
> On Mar 4, 2011, at 4:55 AM, Isaac Marino Bavaresco wrote:
>
>> The repository must contain *everything* necessary to build the final
>> product, except the build tools themselves.
> That "except the build tools themselves" is a huge hole in your  
> philosophy, and a big part of what I was talking about.

The paragraph you snipped out changes things a little:

"I always keep back-ups of the installers for every version of the build
tools I ever used and keep a note on the source files saying what build
tools and versions were used."


Remember that the executables are usually kept on system-specific
directories, it would be hard to keep them on the same tree with the
sources. Besides, to restore a software product is usually not simply a
matter of copying some files to a directory.


Isaac

2011\03\05@020421 by Sean Breheny

face picon face
I want to second BillW's suggestion. A few years ago I had a situation
where a vendor had written code for us and given us the source, but
when we needed to build it, he couldn't remember exactly which version
of the toolchain he used (this was VHDL). There was a bug where it
would only function properly when compiled with exactly a certain
toolset - some optimization difference on other versions was breaking
something in the logic. Of course, this meant that something was
structured in a very fragile way and needed to be fixed, but it would
have helped immensely to be able to at least replicate the binary file
from the source to make sure that we were indeed starting with the
correct source. To make matters worse, the toolset downloaded periodic
updates and its exact state could not be captured by a single version
number. You had to also know the version numbers of all the
subcomponents. It would have been so much better if a history of all
of the upgrades which were applied was kept, which could have been
done easily because each update was a self-extracting file which had
to be manually run. These files could have been checked in along with
the source to keep source+binaries+toolset versioned.

Sean


On Fri, Mar 4, 2011 at 7:51 PM, William "Chops" Westfield
<TakeThisOuTwestfwspamspammac.com> wrote:
{Quote hidden}

>

2011\03\05@075722 by Isaac Marino Bavaresco

flavicon
face
Em 5/3/2011 04:04, Sean Breheny escreveu:
{Quote hidden}

Bill snipped out a paragraph where I explain that I keep copies of the
installers of the building tools and also keep notes on the source code
of what building tools and versions were used.

Isaac

2011\03\07@223720 by Jesse Lackey

flavicon
face
FWIW, I recently updated from visual studio 6 (i.e. circa 1998) to Visual Studio 2008.  I am very impressed with the IDE: it is the best I've ever seen.  VS 2008 is not the latest (VS 2010 came out recently) so it is cheap, like $240 for non-upgrade, non-academic edition.  I have many pointed, on-target (IMHO) criticisms of microsoft's shortcomings, I love to hate them, but they definitely eat their own dog food as they say when it comes to development tools, and VS 2008 is pretty awesome.

That said, my half-million-line windows application development career was most of the 1990s, and not since, so I'm using VS 2008 for pretty trivial windows C++ work, so I can't attest to the scalability of its features.

My 2c.
J



Michael Watterson wrote:
{Quote hidden}

> or 198

2011\03\07@224712 by Jesse Lackey

flavicon
face
To this point ... I was reading how the development environment of some opensource project (debian?  ubuntu?) was delivered as ... an entire virtual machine "image", to run in a VM "player".  So all the tools (compiler and little command-line binaries) and shell settings are delivered instant ready to run, for everyone.  Wow.  Cuts the whole "I can't get it to build what's wrong with my settings/versions" thing right out.

Made me think that would be a good (if perhaps overkill in most instances) way to preserve the State of Things at important moments of time, to be able to replicate bugs discovered years hence as needed, and to be able to do tiny surgical fixes of such with exactly the same toolset that made the final release way back when in 2011.

Neato.

Cheers,
J


Isaac Marino Bavaresco wrote:
{Quote hidden}

2011\03\07@232531 by Oli Glaser

flavicon
face
On 08/03/2011 03:38, Jesse Lackey wrote:
> FWIW, I recently updated from visual studio 6 (i.e. circa 1998) to
> Visual Studio 2008.  I am very impressed with the IDE: it is the best
> I've ever seen.  VS 2008 is not the latest (VS 2010 came out recently)
> so it is cheap, like $240 for non-upgrade, non-academic edition.  I have
> many pointed, on-target (IMHO) criticisms of microsoft's shortcomings, I
> love to hate them, but they definitely eat their own dog food as they
> say when it comes to development tools, and VS 2008 is pretty awesome.
>
> That said, my half-million-line windows application development career
> was most of the 1990s, and not since, so I'm using VS 2008 for pretty
> trivial windows C++ work, so I can't attest to the scalability of its
> features.
>
> My 2c.
> J
>
>

I have VS2008 also (got it a little while after it arrived) and I have to agree. I also have various issues with Microsoft stuff but for speed, convenience and stability VS is hard to beat. The intellisense works extremely well (especially for C# and VB) and the graphical forms design makes doing the more tedious stuff a lot easier/quicker.
I have always been a bit wary of "programming by numbers" type stuff. For example, you can create a database app without writing a single line of code (just drag/drop/set appropriate fields) or a simple internet browser, in which I'm sure many can see the possible dangers. However, that said I also have no problem with tools that make life easier (I just believe it's good to know what is happening "behind the scenes" to a certain extent, although these tools do not preclude that) and VS certainly does. I have tried a few other IDEs (like QT) but I prefer VS for windows apps.



2011\03\08@082126 by Chris McSweeny

picon face
On Tue, Mar 8, 2011 at 3:38 AM, Jesse Lackey <jsl-mlEraseMEspamcelestialaudio.com> wrote:
> they definitely eat their own dog food as they
> say when it comes to development tools, and VS 2008 is pretty awesome.

Maybe that's the secret - they have to make it decent to use because
otherwise their colleagues complain. Lots to hate about most other MS
software I've come across, but VS is great - I say that as somebody
who does use it professionally.

Chri

2011\03\08@183028 by William \Chops\ Westfield

face picon face

On Mar 7, 2011, at 7:48 PM, Jesse Lackey wrote:

> I was reading how the development environment of some
> opensource project (debian?  ubuntu?) was delivered as ... an entire
> virtual machine "image", to run in a VM "player".
>
> Neato.

Yeah, as long as the VM Player in question continues to work...

> Made me think that would be a good way to preserve the
> State of Things at important moments of time

Not a bad idea.  I was thinking from the previous part of this  discussion that a VM would make a good test environment for checking  that your package of SCV'ed stuff actually was able to compile...

It could use some tool development to do this repackaging into a VM.   Right now I think it implies that you actually DO the development  within a VM as well, and I'm not ready to do that. (or to impose my  favorite editor, web browser, and etc on the disk space requirements...)

BillW

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...