[OT?] Simple AND/OR Simplistic single user ~CVS

Tim Wescott wrote:
> On Mon, 23 Nov 2009 12:52:50 -0600, Richard Owlett wrote:
> 
>> For the first time I'm working on a personal project that will have many
>> logical branches and sub-branches.
>>
>> I followed several Google references to CVS :( All were attempts related
>> to "multi this multi that".
>>
>> I'm a SINGLE user on a SINGLE system.
>>
>> What should I search for?
>>
>> TIA
> 
> Have you used any version control systems before?

No.
And, I suspect more importantly, I've never seen one used.

I did a Google search on 4 or 5 of what seemed to be the comp.dsp 
favorites. Looked at a few sites of each and could not determine 
if they could do what I was thinking of.

It *DID* prove that my goal was *VAGUE* ;/
My analogy would be a combination of a well organized filing 
system with aspects of a laboratory notebook.

Any pointers to introduction to version control in general. The 
links I found were to focused on how the described system was 
different.

TIA

Richard Owlett  <rowlett@pcnetinc.com> wrote:

>Tim Wescott wrote:

>> On Mon, 23 Nov 2009 12:52:50 -0600, Richard Owlett wrote:

>>> For the first time I'm working on a personal project that will have many
>>> logical branches and sub-branches.

>>> I followed several Google references to CVS :( All were attempts related
>>> to "multi this multi that".

>>> I'm a SINGLE user on a SINGLE system.

>>> What should I search for?

>> Have you used any version control systems before?

>No.
>And, I suspect more importantly, I've never seen one used.

>I did a Google search on 4 or 5 of what seemed to be the comp.dsp 
>favorites. Looked at a few sites of each and could not determine 
>if they could do what I was thinking of.

>It *DID* prove that my goal was *VAGUE* ;/
>My analogy would be a combination of a well organized filing 
>system with aspects of a laboratory notebook.

>Any pointers to introduction to version control in general. The 
>links I found were to focused on how the described system was 
>different.

CVS is very good (it is used on large, multi-person, multi-year
projects).   It may not be the best for projects with lots
of little branches.  Actually, in that scenario, nothing is
very good.  Consider instead making your code base flexible,
instead of branching the code into different variants.

Steve

Steve Pope wrote:

> CVS is very good (it is used on large, multi-person, multi-year
> projects).

CVS was the only game in town for a long time and when it was the
only game in town nearly every open source project used CVS.

However, CVS stopped being the only game in town a long time
ago and the vast majority of open source projects stopped
using CVS many years ago. The only two exceptions I can think
of are FLAC (whose tree gets about 10 commits per year) and
CSound (which is still very actively developed).

All of the major open source projects are using something else;
Linux kernel (Git), GNU compiler (SVN), Emacs (Bzr) and so on.

>   It may not be the best for projects with lots
> of little branches.  Actually, in that scenario, nothing is
> very good.

I disagree. I use Bzr for libsndfile. At any one time I may
have 5-10 active branches for different features or bugs that
I'm working on. When I'm finished with the feature/bug I
merge it back into the main trunk and delete the branch. Over
the time I've used Bzr for libsndfile I would have had at 
least 60 branches that I kept around for anything from a couple
of hours to a couple of months.

>  Consider instead making your code base flexible,
> instead of branching the code into different variants.

I currently working on someone else's code for a really
interesting compiler written in Haskell:

    http://www.haskell.org/haskellwiki/DDC

I don't know the Haskell programing langauge very well and there
are large chunks of the compiler I simply don't understand. The
work I'm doing on this compiler is fixing bugs from the bug
tracker. I use a separate branch for each bug I'm working on
and whenever I get stuck on one bug I move on to another. So far
I have fixed about 18 bugs and I'm currently working on another
15 or so. Branch per bug-in-progress is the only sane way to work
on smothing like this.

The DDC project uses the Darcs revision control system (also
written in the Haskell programming language).

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Steve Pope wrote:
> Richard Owlett  <rowlett@pcnetinc.com> wrote:
> 
>> Tim Wescott wrote:
> 
>>> On Mon, 23 Nov 2009 12:52:50 -0600, Richard Owlett wrote:
> 
>>>> For the first time I'm working on a personal project that will have many
>>>> logical branches and sub-branches.
> 
>>>> I followed several Google references to CVS :( All were attempts related
>>>> to "multi this multi that".
> 
>>>> I'm a SINGLE user on a SINGLE system.
> 
>>>> What should I search for?
> 
>>> Have you used any version control systems before?
> 
>> No.
>> And, I suspect more importantly, I've never seen one used.
> 
>> I did a Google search on 4 or 5 of what seemed to be the comp.dsp 
>> favorites. Looked at a few sites of each and could not determine 
>> if they could do what I was thinking of.
> 
>> It *DID* prove that my goal was *VAGUE* ;/
>> My analogy would be a combination of a well organized filing 
>> system with aspects of a laboratory notebook.
> 
>> Any pointers to introduction to version control in general. The 
>> links I found were to focused on how the described system was 
>> different.
> 
> CVS is very good (it is used on large, multi-person, multi-year
> projects).   It may not be the best for projects with lots
> of little branches.  Actually, in that scenario, nothing is
> very good.  Consider instead making your code base flexible,
> instead of branching the code into different variants.
> 
> Steve

And just where was the answer to *MY* question ;/

BTW, ROFL I just got my "just deserts"
(the Richter 99 event just occurring was my non-tech friends ROFL)

Erik de Castro Lopo wrote:
> Steve Pope wrote:
> 
>> CVS is very good (it is used on large, multi-person, multi-year
>> projects).
> 
> CVS was the only game in town for a long time and when it was the
> only game in town nearly every open source project used CVS.
> 
> However, CVS stopped being the only game in town a long time
> ago and the vast majority of open source projects stopped
> using CVS many years ago. The only two exceptions I can think
> of are FLAC (whose tree gets about 10 commits per year) and
> CSound (which is still very actively developed).
> 
> All of the major open source projects are using something else;
> Linux kernel (Git), GNU compiler (SVN), Emacs (Bzr) and so on.
> 
>>   It may not be the best for projects with lots
>> of little branches.  Actually, in that scenario, nothing is
>> very good.
> 
> I disagree. I use Bzr for libsndfile. At any one time I may
> have 5-10 active branches for different features or bugs that
> I'm working on. When I'm finished with the feature/bug I
> merge it back into the main trunk and delete the branch. Over
> the time I've used Bzr for libsndfile I would have had at 
> least 60 branches that I kept around for anything from a couple
> of hours to a couple of months.
> 
>>  Consider instead making your code base flexible,
>> instead of branching the code into different variants.
> 
> I currently working on someone else's code for a really
> interesting compiler written in Haskell:
> 
>     http://www.haskell.org/haskellwiki/DDC
> 
> I don't know the Haskell programing langauge very well and there
> are large chunks of the compiler I simply don't understand. The
> work I'm doing on this compiler is fixing bugs from the bug
> tracker. I use a separate branch for each bug I'm working on
> and whenever I get stuck on one bug I move on to another. So far
> I have fixed about 18 bugs and I'm currently working on another
> 15 or so. Branch per bug-in-progress is the only sane way to work
> on smothing like this.
> 
> The DDC project uses the Darcs revision control system (also
> written in the Haskell programming language).
> 
> Erik

You came *CLOSE* to describing my environment.

I have up to ~dozen experiments ongoing.
Many (not all) are related.
Subroutines from any might be useful in another.
I would like to track the successful variants.
     [having them available for cut-n-paste]

Richard Owlett <rowlett@pcnetinc.com> writes:

> Erik de Castro Lopo wrote:
>> Steve Pope wrote:
>>
>>> CVS is very good (it is used on large, multi-person, multi-year
>>> projects).
>>
>> CVS was the only game in town for a long time and when it was the
>> only game in town nearly every open source project used CVS.
>>
>> However, CVS stopped being the only game in town a long time
>> ago and the vast majority of open source projects stopped
>> using CVS many years ago. The only two exceptions I can think
>> of are FLAC (whose tree gets about 10 commits per year) and
>> CSound (which is still very actively developed).
>>
>> All of the major open source projects are using something else;
>> Linux kernel (Git), GNU compiler (SVN), Emacs (Bzr) and so on.
>>
>>>   It may not be the best for projects with lots
>>> of little branches.  Actually, in that scenario, nothing is
>>> very good.
>>
>> I disagree. I use Bzr for libsndfile. At any one time I may
>> have 5-10 active branches for different features or bugs that
>> I'm working on. When I'm finished with the feature/bug I
>> merge it back into the main trunk and delete the branch. Over
>> the time I've used Bzr for libsndfile I would have had at least 60
>> branches that I kept around for anything from a couple
>> of hours to a couple of months.
>>
>>>  Consider instead making your code base flexible,
>>> instead of branching the code into different variants.
>>
>> I currently working on someone else's code for a really
>> interesting compiler written in Haskell:
>>
>>     http://www.haskell.org/haskellwiki/DDC
>>
>> I don't know the Haskell programing langauge very well and there
>> are large chunks of the compiler I simply don't understand. The
>> work I'm doing on this compiler is fixing bugs from the bug
>> tracker. I use a separate branch for each bug I'm working on
>> and whenever I get stuck on one bug I move on to another. So far
>> I have fixed about 18 bugs and I'm currently working on another
>> 15 or so. Branch per bug-in-progress is the only sane way to work
>> on smothing like this.
>>
>> The DDC project uses the Darcs revision control system (also
>> written in the Haskell programming language).
>>
>> Erik
>
> You came *CLOSE* to describing my environment.
>
> I have up to ~dozen experiments ongoing.
> Many (not all) are related.
> Subroutines from any might be useful in another.
> I would like to track the successful variants.
>     [having them available for cut-n-paste]

Subversion has the same capability for branching and then
merging changes back in. I'd imagine most modern version
control systems do.

In fact, TortoiseSVN (the svn client for Windows that is a Windows
Explorer shell extension, i.e., integrated with Windows Explorer) has a
very handy "Repo Browser" that gives you an Explorer-like view of all
your branches, tags, and the trunk, so you can view or copy the contents
of any revision of any one.
-- 
Randy Yates                      % "And all you had to say
Digital Signal Labs              %  was that you were 
mailto://yates@ieee.org          %  gonna stay."
http://www.digitalsignallabs.com % Getting To The Point', *Balance of Power*, ELO

On Wed, 25 Nov 2009 06:01:50 -0600, Richard Owlett wrote:

> Tim Wescott wrote:
>> On Mon, 23 Nov 2009 12:52:50 -0600, Richard Owlett wrote:
>> 
>>> For the first time I'm working on a personal project that will have
>>> many logical branches and sub-branches.
>>>
>>> I followed several Google references to CVS :( All were attempts
>>> related to "multi this multi that".
>>>
>>> I'm a SINGLE user on a SINGLE system.
>>>
>>> What should I search for?
>>>
>>> TIA
>> 
>> Have you used any version control systems before?
> 
> No.
> And, I suspect more importantly, I've never seen one used.
> 
> I did a Google search on 4 or 5 of what seemed to be the comp.dsp
> favorites. Looked at a few sites of each and could not determine if they
> could do what I was thinking of.
> 
> It *DID* prove that my goal was *VAGUE* ;/ My analogy would be a
> combination of a well organized filing system with aspects of a
> laboratory notebook.
> 
> Any pointers to introduction to version control in general. The links I
> found were to focused on how the described system was different.
> 
> TIA

I've looked and haven't found anything, so here's a brief rundown:

Why version control?  Because _you_ can't go home again, but there's no 
reason your code shouldn't.  Let me tell you a story about what a _lack_ 
of version control can do for you:

I had a really nice client once.  They were doing neato stuff in the 
petroleum extraction biz, transmitting data as pressure pulses in the 
driller's mud from waaaaaaay down there in the ground.  I was working 
with them on their receiver algorithms, making them more robust in the 
face of noise, etc.

I got to a nice milepost, we all agreed that this was a good enough 
improvement to ship product, so they said "leave us alone for a month, 
we'll get back to you".  So I did, and I left them alone for another 
couple of weeks, then I sent them a nice 'ping' email asking how things 
were going.  I got a very short reply "we accidentally released code with 
some old bugs in it -- we're working on a fix, can we get back to you?"

Sure I said -- what else could I do?

Well, I pinged them again a few times and never heard anything back -- 
until I got the nice letter from the folks that had bought their remains 
out of bankruptcy.

Now, a version control system by itself couldn't have prevented this.  
But a version control system, implementing a version control policy that 
was tied into a release policy -- that could have _easily_ prevented this.

What is version control?  It's a way of keeping track of older revisions 
in your code base.  Implemented correctly it means that any time you 
reach a milestone ("Hey!  The lights blink!") you can mark _all_ of the 
files in the project as going with that version of code.  You can do it 
easily, so you can capture incremental improvements ("Hey!  The lights 
blink _in the correct order_!").  More important, you can go _back_ 
("Hey!  Ever since we made the lights blink from left to right the data 
collection has been busted!"), either wholesale ("and we gotta ship!") or 
file by file ("the problem's just in zygote.c").  Further you can easily 
do compares with old versions to track the problem down.

How do you use version control?

Every version control system lets you do the same basic operations, 
although the way that it happens, the language it's described in, and the 
way you make it happen may all vary widely.

Here's a (probably incomplete) list of what you can do:

- check existing files out, either by label (i.e. "LIGHTS_BLINK")
  by date, or as 'tip' (i.e. the absolute newest files ever, or
  at least the newest file on the 'trunk').

- get files just for building, not for working on (this is part of
  a good release policy).

- check your work in.

- create new files in the revision control system.

- Branch and merge.  If you're working on 10 different views of
  something, or if you're one of 10 developers, you don't want me
  checking my stuff in on top of yours, because I may break your build.
  (and much as I like you, I don't want the reverse happening).
  So a decent VCS let's you 'branch' code, either as individual files
  or (with newer ones) as little sub-projects.  You branch, you work
  on one problem in one branch as if it's the only code base in the
  world, then when you _know_ you like it you merge it back into
  the 'main line', or trunk.

- Label, or otherwise designate, snapshots of the code base to go
  with significant events.  A decent release policy says that you ONLY
  EVER ship code that's been built from code that's been checked out
  blind, by label, into a virgin build environment -- if it won't
  build unless Fred comes over and tweaks collectedbugs.c to make
  it compile, then you don't even _think_ about shipping.

The work flow for modifications to an existing software base go something 
like this:

1: Create a new branch
2: Check out files (this may be part of creating the new branch, or not)
3: Do your work, checking in versions regularly, and possibly
   labeling your work whenever things are cooking along right.
4: When you're happy, check _everything_ in.
5: Get it all into a virgin build environment, build and test.
   Go back in the process as necessary to fix bugs.
6: Ship.

In a group environment, step 6 would be "hand it over to the build & test 
group", then _they_ would build the 'real' version for shipment, test it, 
possibly make you go back and fix bugs, etc.

The beauty of a version control system is that you can do things like:

Go back to code that you've shipped, possibly ages ago, fix one bug and 
release without disturbing the trunk (and without pouring the whole trunk 
development into something you want to turn quickly).

Do it again for some completely different shipped version.

Or maintain a special branch for one customer with features specific to 
them.

Or maintain several special branches for several special customers.

There's more, but I've got to go cook dinner -- hopefully this'll help, 
and maybe others will chime in to point out all the bits I left out.

-- 
www.wescottdesign.com

On Wed, 25 Nov 2009 06:01:50 -0600, Richard Owlett wrote:

> Tim Wescott wrote:
>> On Mon, 23 Nov 2009 12:52:50 -0600, Richard Owlett wrote:
>> 
>>> For the first time I'm working on a personal project that will have
>>> many logical branches and sub-branches.
>>>
>>> I followed several Google references to CVS :( All were attempts
>>> related to "multi this multi that".
>>>
>>> I'm a SINGLE user on a SINGLE system.
>>>
>>> What should I search for?
>>>
>>> TIA
>> 
>> Have you used any version control systems before?
> 
> No.
> And, I suspect more importantly, I've never seen one used.
> 
> I did a Google search on 4 or 5 of what seemed to be the comp.dsp
> favorites. Looked at a few sites of each and could not determine if they
> could do what I was thinking of.
> 
> It *DID* prove that my goal was *VAGUE* ;/ My analogy would be a
> combination of a well organized filing system with aspects of a
> laboratory notebook.
> 
> Any pointers to introduction to version control in general. The links I
> found were to focused on how the described system was different.
> 
> TIA

How's this?

http://www.ericsink.com/scm/source_control.html.

Wikipedia also goes over the basics in its entry on version control.

-- 
www.wescottdesign.com

Erik de Castro Lopo  <erikd@mega-nerd.com> wrote:

>Steve Pope wrote:

[CVS]

>> It may not be the best for projects with lots
>> of little branches.  Actually, in that scenario, nothing is
>> very good.

>I disagree. I use Bzr for libsndfile. At any one time I may
>have 5-10 active branches for different features or bugs that
>I'm working on. When I'm finished with the feature/bug I
>merge it back into the main trunk and delete the branch. Over
>the time I've used Bzr for libsndfile I would have had at 
>least 60 branches that I kept around for anything from a couple
>of hours to a couple of months.

Erik, thanks for adding this information.

Steve

Tim Wescott wrote:
> On Wed, 25 Nov 2009 06:01:50 -0600, Richard Owlett wrote:
> 
>> Tim Wescott wrote:
>>> On Mon, 23 Nov 2009 12:52:50 -0600, Richard Owlett wrote:
>>>
>>>> For the first time I'm working on a personal project that will have
>>>> many logical branches and sub-branches.
>>>>
>>>> I followed several Google references to CVS :( All were attempts
>>>> related to "multi this multi that".
>>>>
>>>> I'm a SINGLE user on a SINGLE system.
>>>>
>>>> What should I search for?
>>>>
>>>> TIA
>>> Have you used any version control systems before?
>> No.
>> And, I suspect more importantly, I've never seen one used.
>>
>> I did a Google search on 4 or 5 of what seemed to be the comp.dsp
>> favorites. Looked at a few sites of each and could not determine if they
>> could do what I was thinking of.
>>
>> It *DID* prove that my goal was *VAGUE* ;/ My analogy would be a
>> combination of a well organized filing system with aspects of a
>> laboratory notebook.
>>
>> Any pointers to introduction to version control in general. The links I
>> found were to focused on how the described system was different.
>>
>> TIA
> 
> I've looked and haven't found anything, so here's a brief rundown:
> 
> Why version control?  Because _you_ can't go home again, but there's no 
> reason your code shouldn't.  Let me tell you a story about what a _lack_ 
> of version control can do for you:
> 
> I had a really nice client once.  They were doing neato stuff in the 
> petroleum extraction biz, transmitting data as pressure pulses in the 
> driller's mud from waaaaaaay down there in the ground.  I was working 
> with them on their receiver algorithms, making them more robust in the 
> face of noise, etc.
> 
> I got to a nice milepost, we all agreed that this was a good enough 
> improvement to ship product, so they said "leave us alone for a month, 
> we'll get back to you".  So I did, and I left them alone for another 
> couple of weeks, then I sent them a nice 'ping' email asking how things 
> were going.  I got a very short reply "we accidentally released code with 
> some old bugs in it -- we're working on a fix, can we get back to you?"
> 
> Sure I said -- what else could I do?
> 
> Well, I pinged them again a few times and never heard anything back -- 
> until I got the nice letter from the folks that had bought their remains 
> out of bankruptcy.
> 
> Now, a version control system by itself couldn't have prevented this.  
> But a version control system, implementing a version control policy that 
> was tied into a release policy -- that could have _easily_ prevented this.
> 
> What is version control?  It's a way of keeping track of older revisions 
> in your code base.  Implemented correctly it means that any time you 
> reach a milestone ("Hey!  The lights blink!") you can mark _all_ of the 
> files in the project as going with that version of code.  You can do it 
> easily, so you can capture incremental improvements ("Hey!  The lights 
> blink _in the correct order_!").  More important, you can go _back_ 
> ("Hey!  Ever since we made the lights blink from left to right the data 
> collection has been busted!"), either wholesale ("and we gotta ship!") or 
> file by file ("the problem's just in zygote.c").  Further you can easily 
> do compares with old versions to track the problem down.
> 
> How do you use version control?
> 
> Every version control system lets you do the same basic operations, 
> although the way that it happens, the language it's described in, and the 
> way you make it happen may all vary widely.
> 
> Here's a (probably incomplete) list of what you can do:
> 
> - check existing files out, either by label (i.e. "LIGHTS_BLINK")
>   by date, or as 'tip' (i.e. the absolute newest files ever, or
>   at least the newest file on the 'trunk').
> 
> - get files just for building, not for working on (this is part of
>   a good release policy).
> 
> - check your work in.
> 
> - create new files in the revision control system.
> 
> - Branch and merge.  If you're working on 10 different views of
>   something, or if you're one of 10 developers, you don't want me
>   checking my stuff in on top of yours, because I may break your build.
>   (and much as I like you, I don't want the reverse happening).
>   So a decent VCS let's you 'branch' code, either as individual files
>   or (with newer ones) as little sub-projects.  You branch, you work
>   on one problem in one branch as if it's the only code base in the
>   world, then when you _know_ you like it you merge it back into
>   the 'main line', or trunk.
> 
> - Label, or otherwise designate, snapshots of the code base to go
>   with significant events.  A decent release policy says that you ONLY
>   EVER ship code that's been built from code that's been checked out
>   blind, by label, into a virgin build environment -- if it won't
>   build unless Fred comes over and tweaks collectedbugs.c to make
>   it compile, then you don't even _think_ about shipping.
> 
> The work flow for modifications to an existing software base go something 
> like this:
> 
> 1: Create a new branch
> 2: Check out files (this may be part of creating the new branch, or not)
> 3: Do your work, checking in versions regularly, and possibly
>    labeling your work whenever things are cooking along right.
> 4: When you're happy, check _everything_ in.
> 5: Get it all into a virgin build environment, build and test.
>    Go back in the process as necessary to fix bugs.
> 6: Ship.
> 
> In a group environment, step 6 would be "hand it over to the build & test 
> group", then _they_ would build the 'real' version for shipment, test it, 
> possibly make you go back and fix bugs, etc.
> 
> The beauty of a version control system is that you can do things like:
> 
> Go back to code that you've shipped, possibly ages ago, fix one bug and 
> release without disturbing the trunk (and without pouring the whole trunk 
> development into something you want to turn quickly).
> 
> Do it again for some completely different shipped version.
> 
> Or maintain a special branch for one customer with features specific to 
> them.
> 
> Or maintain several special branches for several special customers.
> 
> There's more, but I've got to go cook dinner -- hopefully this'll help, 
> and maybe others will chime in to point out all the bits I left out.
> 

Yes it definitely helped.

I've also gotten thru
   http://en.wikipedia.org/wiki/Version_control   and
   http://www.ericsink.com/scm/source_control.html
which you suggested in your following post.

I'm just starting _Version Control with Subversion_
( http://svnbook.red-bean.com ) and have downloaded  TortoiseSVN.

We'll just how "interesting" life becomes for the next few weeks 
(eons?).