CVS

I am struggling to come to terms with how to work with a CVS . I am a sole
developer, and I want to avoid the situation I am in now (package hell) and
organise my sources/packages and projects more effectively.

I have downloaded WinCvs, and was able to set up a local repository. I also
filed a package out from an image in pax format. I think I "imported" it
properly, and I was able to check it out to another directory.

I just dont see how to work this into a day to day routine. I do like the
idea of versions (rather than backing up an image to go back to if changes
dont work out) and  I like the idea of changes in a package being reflected
in all my projects that use that package (rather than package hell).

How do I go about setting up Dolphin and CVS, so that I can have seperate
logical projects, sharing packages?

Thanks
Steve

I haven't played with CVS (although I'm about to exercise PAX in the Dolphin
4 version of Swazoo which should be up on SourceForge soon), but you might
want to look at David Gorisek's Source Tracking System.  It's pretty much
transparent, you tell it to track something and it handles the versioning
for you.  I'm sure I'm not using it to its full capacity, mainly I use it to
'go back in time' to earlier versions of methods which I've managed to screw
up.  I'm still learning the system- basically I learn how to use the various
tools as I need them.

I like it because it fits into the rest of the environment smoothly - I
don't have to worry about checking in and out stuff from a repository.

I would highly recommend it- plus, it looks like there are some nice
enhancements in the pipeline.  But, you might want to talk with David
directly to ask about the more advanced features, using multiple images,
etc.  You can reach him at: [hidden email]

Hope this helps.

-Jerry


Steve Waring <[hidden email]> wrote in message
news:uSCS5.141528$[hidden email]...
> I am struggling to come to terms with how to work with a CVS . I am a sole
> developer, and I want to avoid the situation I am in now (package hell)
and
> organise my sources/packages and projects more effectively.
>
> I have downloaded WinCvs, and was able to set up a local repository. I
also
> filed a package out from an image in pax format. I think I "imported" it
> properly, and I was able to check it out to another directory.
>
> I just dont see how to work this into a day to day routine. I do like the
> idea of versions (rather than backing up an image to go back to if changes
> dont work out) and  I like the idea of changes in a package being
reflected
> in all my projects that use that package (rather than package hell).
>
> How do I go about setting up Dolphin and CVS, so that I can have seperate
> logical projects, sharing packages?
>
> Thanks
> Steve
>
>

Jerry thanks for the compliments!

I also read c.l.s.d here and then so let me explain what STS is and what's in
the pipeline for the next release.
Basically, Source Tracking System tries to be an ENVY clone for Dolphin (I'll
need it in case IBM decides to drop VAST ;-)). For people who've used ENVY it
shouln't be difficult to use it, although there are differences. STS uses a
file-based multi-user object database as a source code repository. It versions
methods, classes, packages and in the forthcoming version also projects. A
project in STS is like a configuration map in ENVY. A project bundles package
versions together so that the next time you are loading the code of the product
you're working on, you don't have to think about which version of the frameworks
package you have to load as a prerequisite of you product package. Everything
that's versioned in STS gets its timestamp, version descriptor (only packages
and projects) and developer information. So basically for everything you do in
Dolphin you know who did what and when.
Apart from just versioning everything you also have powerfull tools with which
you can compare versions with each other and merge code together when more
people are working on the same package.
There is no need to check-in/out code since no one can ever change a package
once it's versioned. A package version will always stay the same so that
everyone can change code and all you have to know is which version is the right
one. The new version will also introduce package and project history tree which
is a special window in which a graphical tree of all versions will be showing
all branches and versions that development diverged into (something to keep
these ClearCase users drooling :-)).
Well, I intend to release the 2.0 version shortly as my free time (and weather)
permits and I've already sent the beta to everyone who's entitled to a free
upgrade.

David

Jerry Bell wrote:

Hi David and Jerry,

Thanks for the info, STS sounds like a much easier, and more efficient way
to go than WinCvs etc.

David, I have looked through your web site, but I get no response from the
server when trying to download the trial beta version for Dolphin V4. Is
that package still available, or should I wait until you are ready to go
with v2.0?

I think I understand the mechanics of your system. I think in terms of the
projects I am working on, and the classes in those projects. I have only
been able to make use of packages to transport a set of classes from one
image to another. I would think that being able to version a package would
allow me to refactor across packages in one project, and then at my leisure
either incorporate those changes into other projects, or split the tree.
This would make packages within a project much more useful for me.

I create image backups for two reasons, the first is to bluntly go back to
older version of my code if I dont like the changes I have made. STS looks
like it is designed to do this in a much more effective way than I go about
it.

The second is if I am about to do something which may corrupt my image, or
if I have just done something stupid and generated a GPF walkback, which
doesnt "multiply" during the next GC. Using this strategy, I have never
saved down a bad image, nor lost any work that couldnt be extracted from my
change.log

Assuming no lack of disk space, would I be able to achieve the same level of
protection if I was using STS? How resistant to corruption are the
additional files that STS creates? Between any action that writes to the
change.log etc, are the additional files in some kind of consistent state
which I could do some kind of full backup, with full confidence that I could
restore to a last known good state? Are these additional files even updated
along side the change.log, or are changes only made to the additional files
when I choose to create a version?

I think that if there is some backup strategy I can follow to give me this
confidence then my only other question is; how is the weather looking in
your part of the world :)

Thanks,
Steve
swaring at ozemail dot com dot au

"David Gorisek" <[hidden email]> wrote in message
news:[hidden email]...
> Jerry thanks for the compliments!
>
> I also read c.l.s.d here and then so let me explain what STS is and what's
in
> the pipeline for the next release.
> Basically, Source Tracking System tries to be an ENVY clone for Dolphin
(I'll
> need it in case IBM decides to drop VAST ;-)). For people who've used ENVY
it
> shouln't be difficult to use it, although there are differences. STS uses
a
> file-based multi-user object database as a source code repository. It
versions
> methods, classes, packages and in the forthcoming version also projects. A
> project in STS is like a configuration map in ENVY. A project bundles
package
> versions together so that the next time you are loading the code of the
product
> you're working on, you don't have to think about which version of the
frameworks
> package you have to load as a prerequisite of you product package.
Everything
> that's versioned in STS gets its timestamp, version descriptor (only
packages
> and projects) and developer information. So basically for everything you
do in
> Dolphin you know who did what and when.
> Apart from just versioning everything you also have powerfull tools with
which
> you can compare versions with each other and merge code together when more
> people are working on the same package.
> There is no need to check-in/out code since no one can ever change a
package
> once it's versioned. A package version will always stay the same so that
> everyone can change code and all you have to know is which version is the
right
> one. The new version will also introduce package and project history tree
which
> is a special window in which a graphical tree of all versions will be
showing
> all branches and versions that development diverged into (something to
keep
> these ClearCase users drooling :-)).
> Well, I intend to release the 2.0 version shortly as my free time (and
weather)
> permits and I've already sent the beta to everyone who's entitled to a
free
> upgrade.
>
> David
>
> Jerry Bell wrote:
>
> > I haven't played with CVS (although I'm about to exercise PAX in the
Dolphin
> > 4 version of Swazoo which should be up on SourceForge soon), but you
might
> > want to look at David Gorisek's Source Tracking System.  It's pretty
much
> > transparent, you tell it to track something and it handles the
versioning
> > for you.  I'm sure I'm not using it to its full capacity, mainly I use
it to
> > 'go back in time' to earlier versions of methods which I've managed to
screw
> > up.  I'm still learning the system- basically I learn how to use the
various

Steve,

> David, I have looked through your web site, but I get no response from the
> server when trying to download the trial beta version for Dolphin V4. Is
> that package still available, or should I wait until you are ready to go
> with v2.0?

Actually, this wasn't a STS 2.0 but a STS 1.1 ported to Dolphin 4.0 beta 2.
Therefore it won't work with the final Dolphin 4.0 release anyway.
Now, I don't know why the download fails but downloading the STS 1.1 for
Dolphin 3.06 still works so if you still have the old version you can grab
this on and give it a try.

> Assuming no lack of disk space, would I be able to achieve the same level
of
> protection if I was using STS? How resistant to corruption are the
> additional files that STS creates? Between any action that writes to the
> change.log etc, are the additional files in some kind of consistent state
> which I could do some kind of full backup, with full confidence that I
could
> restore to a last known good state? Are these additional files even
updated
> along side the change.log, or are changes only made to the additional
files
> when I choose to create a version?

STS uses an object database which is very robust since it's got transactions
and everything what you would expect from a database. So each time you save
a method there will be another method edition created in the repository. And
each time you version a package there will be another version of that
particular package and all of the classes that have changed in the
repository. Afterwards you can always check what changes you've done in your
image compared to the version in the repository (and even what are the
differences between any two versions in the repository). So if you need to,
you can always load some older version of a class, package or a method (and
even view resource) from repository.
STS doesn't do what change.log does, i.e. it doesn't automatically log all
changes into repository. It just stores versions of a
method/class/package/project. For a method, each save will make a new
version. Whereas for the package or class it will make a new version only
after you've selected 'Version...' inside the Package Browser. So, while all
the changes that you do are stored in the repository you still have to get
them all together by loading method editions separately or by using the
change.log.

 > I think that if there is some backup strategy I can follow to give me
this
> confidence then my only other question is; how is the weather looking in
> your part of the world :)

Today the weather is sunny which is bad for programming ;-)

Greetings from the sunny side of the Alps,

David