Advise on new VCS
Arjan de Haan
I'm charged with selecting a new version control system for a small team
of developers. Currently we're using (shudder) VSS, but are having many
problems with it. I have googled, but came up with so much information I
started to get information overload. I'm hoping anybody can help...:-)
I don't care if it is open source or commercial (albeit with normal
license costs; we're a small shop) but would like it to match most if
not all of the following (in order of precedence):
1) centralized repository,
2) promotion groups, preferably NOT by (mis)using labels,
3) support for file groups: handling related files as one checkin/checkout,
4) change lists, or change sets,
5) pre- and post checkin actions,
6) command line API, so we can use tools like CruiseControl or Visual Build,
7) IDE (VS2008) integration would be nice
Hopefully some of you readers can offer me suggestions on what systems
would fit the bill.
Tx for any help in this.
...Arjan...
Jorgen Grahn
Much of your terminology is unknown to me, but ...
Subversion is the default choice for lots of people these days; it is
used in many places, lots of people are familiar with it, and there is
(I assume) glue for all kinds of IDEs and other tools.
I'm not saying I recommend SVN or that it would match your
requirements; just that it has an advantage by being in wide use and
(unlike Source Safe) widely liked.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
Ron Ruble
> On Sat, 21 Feb 2009 10:57:33 +0100, Arjan de Haan <adwhaan_remove_this@raketnet._remove_this_too.nl> wrote:
>> Hi.
>>
>> I'm charged with selecting a new version control system for a small team
>> of developers. Currently we're using (shudder) VSS, but are having many
>> problems with it. I have googled, but came up with so much information I
>> started to get information overload. I'm hoping anybody can help...:-)
>>
>> I don't care if it is open source or commercial (albeit with normal
>> license costs; we're a small shop) but would like it to match most if
>> not all of the following (in order of precedence):
>>
>> 1) centralized repository,
Subversion supports a central repository. It actually has a server,
unlike VSS.
>> 2) promotion groups, preferably NOT by (mis)using labels,
Subversion uses a rather unusual approach to labels (tags) and
branches, I would download the SVN Book from the subversion
website and read it. Google for it.
>> 3) support for file groups: handling related files as one checkin/checkout,
Subversion applies a revision number to the entire respository
when you do a checkin. Typically, you checkout an entire folder
tree. Note that Subversion, like most VCS (but not VSS), does not
use exclusive locking, but contents to detect changes.
>> 4) change lists, or change sets,
Depends on how you look at those things.
>> 5) pre- and post checkin actions,
You got it; SVN supports scripts that act as hooks. There are some
examples on the SVN website. They can be python, bash, ruby,
whatever.
>> 6) command line API, so we can use tools like CruiseControl or Visual Build,
SVN is command-line, but there are GUI front ends.
>> 7) IDE (VS2008) integration would be nice
The Ankh plugin supports this for SVN. I'm not a big fan of VS
integration, but it is -much- better than VSS, in my opinion.
>> Hopefully some of you readers can offer me suggestions on what systems
>> would fit the bill.
>> Tx for any help in this.
>
> Much of your terminology is unknown to me, but ...
>
> Subversion is the default choice for lots of people these days; it is
> used in many places, lots of people are familiar with it, and there is
> (I assume) glue for all kinds of IDEs and other tools.
>
> I'm not saying I recommend SVN or that it would match your
> requirements; just that it has an advantage by being in wide use and
> (unlike Source Safe) widely liked.
>
> /Jorgen
>
In addition to SVN, which is very standard (SourceForge offers
SVN as well as CVS), GIT is attracting a lot of attention,
and I've heard good things about Mercurial.
I use SVN, personally, but what I've seen of GIT is very
attractive.
With any of them, you're going to have some learning and
unlearning to do; take advantage of the public documentation
and look them over. Since SVN and GIT are free to download,
play with them a bit.
Sam
Hi Arjan,
NOTE: I am a consultant who is currenty working at Spectrum (SCM
Vendor).
There are a lot of commercial SCM tools in addition to the FREE tools
such as Subversion which you can consider.
Depending on your exact licensing and technical needs/SCM goals they
all may be able to meet your needs.
Based on what you have described as your need, please checkout our
platform independent SCM tool SpectrumSCM ( www.spectrumscm.com )
which I feel will fit both your technical needs and and at a very
affordable cost. It is also considered to be a strong process-centric
and full featured SCM system. In fact all of the items you have listed
abovee SpectrumSCM has very good feature set to address all of these
and more. There are offcourse of other
SpectrumSCM, is considered industry's first truly
integrated, process-centric, platform independent,
full-featured (Version Control, Issue/Defect Tracking, Change
Management, Process Management, Workflow,
Release Management, , Advanced branching techniques, Parallel
Development) Source Configuration Management
system in the market place. SpectrumSCM brings in the best practices
for automation of Project lifecycle processes
through unified configuration management and change management by
providing full CM functionality with one truly
integrated SCM system and not as a suite of bundled applications.
NOTE: We currently have four Great Licensing Package offers for small
and medium sized project teams. This special
offering is to encourage smaller development teams and new customers
to procure and benefit from the fully-integrated
solution offered by SpectrumSCM. This offer will be effective until
March 31st, 2009. This offer has been a great
success amongst our new customers and smaller teams.
Until March 31st, 2009, We are offering for first time buyers and new
users a 5-user (floating licenses) package which
includes the SpectrumSCM Server for FREE ($1,500 savings) or a 10-user
(floating licenses) package, which also
includes the SpectrumSCM Server. There are also special 25-user and a
50-user package.
This is to encourage even the smallest teams to benefit from the best
CM practices and provides high-end CM capability
at the price of a competitor’s single function tool (i.e VSS, Perforce
etc or any of the high-end full featured SCM tools)
from the get go.
If you are keen to learn more about the SpectrumSCM product please
feel free to send me an separate email, or
visit www.spectrumscm.com.
If you find SpectrumSCM has kindled your interest further , feel free
to contact
sa...@spectrumscm.com or myself. You can also download a FREE 60-day
trial license if that is helps you with your evaluation.
The trial version is the complete tool and has all of the
functionalities.
Hope this helps.
Cheers
- Sam
www.spectrumscm.com
Arjan de Haan
>
> Based on what you have described as your need, please checkout our
> platform independent SCM tool SpectrumSCM ( www.spectrumscm.com )
> which I feel will fit both your technical needs and and at a very
> affordable cost. It is also considered to be a strong process-centric
> and full featured SCM system. In fact all of the items you have listed
> abovee SpectrumSCM has very good feature set to address all of these
> and more. There are offcourse of other
>
Thank you Sam. I'll check out your product.
...Arjan...
Arjan de Haan
>>> 2) promotion groups, preferably NOT by (mis)using labels,
>
> Subversion uses a rather unusual approach to labels (tags) and
> branches, I would download the SVN Book from the subversion
> website and read it. Google for it.
>
I keep this in mind.
>>> 3) support for file groups: handling related files as one
>>> checkin/checkout,
>
> Subversion applies a revision number to the entire respository
> when you do a checkin. Typically, you checkout an entire folder
> tree. Note that Subversion, like most VCS (but not VSS), does not
> use exclusive locking, but contents to detect changes.
>
A bit odd. Sounds more like snapshots to me. And checking out an entire
folder...many times two or more of our developers are working on
different files within the same folder. Something to keep in mind. Tx.
>>> 4) change lists, or change sets,
>
> Depends on how you look at those things.
>
Not sure what you mean. I see a changelist/set as a pre-checkin portal.
It means I can check in certain sources, make a few changes to other
related sources and check those in too, before committing all those
sources as one atomic operation.
> In addition to SVN, which is very standard (SourceForge offers
> SVN as well as CVS), GIT is attracting a lot of attention,
> and I've heard good things about Mercurial.
I will add GIT to my list to check out (pun intended).
Thank you.
...Arjan...
Jorgen Grahn
> Ron Ruble wrote:
>
>>>> 2) promotion groups, preferably NOT by (mis)using labels,
>>
>> Subversion uses a rather unusual approach to labels (tags) and
>> branches, I would download the SVN Book from the subversion
>> website and read it. Google for it.
>>
>
> I keep this in mind.
>
>>>> 3) support for file groups: handling related files as one
>>>> checkin/checkout,
>>
>> Subversion applies a revision number to the entire respository
>> when you do a checkin. Typically, you checkout an entire folder
>> tree. Note that Subversion, like most VCS (but not VSS), does not
>> use exclusive locking, but contents to detect changes.
>>
>
> A bit odd. Sounds more like snapshots to me.
Is "snapshot" VSS terminology, perhaps? I guess he meant to say "you
typically commit all your changes at once, with the same checkin
comment, rather than painfully file-by-file". I do not use GUIs, but
I hope GUIs on top of SVN encourage this way of working.
> And checking out an entire
> folder...many times two or more of our developers are working on
> different files within the same folder. Something to keep in mind. Tx.
"Checking out" as you use the term applies to tools which use
exclusive locking. SVN doesn't, so in your case you have N people
editing the same set of files and commiting their changes. The first
to commit wins; the others will have to update (integrate the recent
repository changes in their working copies) before they can commit.
(If they work on the same branch, that is.)
Ron Ruble
> Ron Ruble wrote:
>
>>>> 2) promotion groups, preferably NOT by (mis)using labels,
>>
>> Subversion uses a rather unusual approach to labels (tags) and
>> branches, I would download the SVN Book from the subversion
>> website and read it. Google for it.
>>
> I keep this in mind.
>
>>>> 3) support for file groups: handling related files as one
>>>> checkin/checkout,
>>
>> Subversion applies a revision number to the entire respository
>> when you do a checkin. Typically, you checkout an entire folder
>> tree. Note that Subversion, like most VCS (but not VSS), does not
>> use exclusive locking, but contents to detect changes.
>>
> A bit odd. Sounds more like snapshots to me. And checking out an entire
> folder...many times two or more of our developers are working on
> different files within the same folder. Something to keep in mind. Tx.
Right; and merge rather than lock based management means that
when another developer has changed something in the folder/project
you are updating, you can update you local folder from the
repository and pick up their changes to test against yours
-- without -- blowing away your own local changes.
If you have a conflict, you can revert. Ultimately, it's much
safer.
I expected the comment that it seems odd. Moving to any of the
more sophisticated CM tools from VSS will require you to change
some of your ways of looking at things, and the SVN approach
is unusual in several ways. SVN's branching and tags are based
around the idea of "cheap copies", basically a hard-link
with copy on write support.
The SVN book (free download from the tigris site) goes into
lots of detail.
>>>> 4) change lists, or change sets,
>>
>> Depends on how you look at those things.
>>
>
> Not sure what you mean. I see a changelist/set as a pre-checkin portal.
> It means I can check in certain sources, make a few changes to other
> related sources and check those in too, before committing all those
> sources as one atomic operation.
This sounds like a use for branching. Make a branch, merge in
additional changes from another branch, and then merge the
entire branch into the trunk.
You can apply different rights to different folders and use
pre and post-commit hooks to support what you seem to be
trying to do.
>> In addition to SVN, which is very standard (SourceForge offers
>> SVN as well as CVS), GIT is attracting a lot of attention,
>> and I've heard good things about Mercurial.
>
> I will add GIT to my list to check out (pun intended).
> Thank you.
>
> ...Arjan...
Also check out the literature on the subject. There are a
lot of features in various CM tools that VSS doesn't support,
so there are probably things you want to learn about before
committing to a tool.
Arjan de Haan
>
> The SVN book (free download from the tigris site) goes into
> lots of detail.
>
I'll check it out.
>>>>> 4) change lists, or change sets,
>>>
>>> Depends on how you look at those things.
>>>
>>
>> Not sure what you mean. I see a changelist/set as a pre-checkin
>> portal. It means I can check in certain sources, make a few changes to
>> other related sources and check those in too, before committing all
>> those sources as one atomic operation.
>
> This sounds like a use for branching. Make a branch, merge in
> additional changes from another branch, and then merge the
> entire branch into the trunk.
>
> You can apply different rights to different folders and use
> pre and post-commit hooks to support what you seem to be
> trying to do.
>
Hm. Changesets aren't usually meant as a replacement for branching, just
to allow you to group relevant, changed sources in one commit. I know
that can be done without changesets, but the concept is (from my POV) handy.
I'm assuming _you_ mean one can achieve a similar thing like changesets
in SVN by using branching.
Most of the time you see that a changeset can be related to an issue;
this effectively marks all sources (and revisions) in the changeset are
being related to that issue. It's a logical grouping of sources, and the
changeset can be handled as a logical unit (not checked yet, but I
assume that if I get the latest version of a changeset I only get the
specific revisions of all the sources in that changeset).
>
> Also check out the literature on the subject. There are a
> lot of features in various CM tools that VSS doesn't support,
> so there are probably things you want to learn about before
> committing to a tool.
That I gathered by looking around....LOL. We VSS users have been
deprived from many a nice feature!
Tx.
...Arjan...
Hendrik Schober
> [...]
> Hm. Changesets aren't usually meant as a replacement for branching, just
> to allow you to group relevant, changed sources in one commit. I know
> that can be done without changesets, but the concept is (from my POV) handy.
> I'm assuming _you_ mean one can achieve a similar thing like changesets
> in SVN by using branching.
> Most of the time you see that a changeset can be related to an issue;
> this effectively marks all sources (and revisions) in the changeset are
> being related to that issue. It's a logical grouping of sources, and the
> changeset can be handled as a logical unit (not checked yet, but I
> assume that if I get the latest version of a changeset I only get the
> specific revisions of all the sources in that changeset).
The closest to what you describe in SVN is probably changelists:
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.changelists
Unless I misunderstood, that is.
> [...]
> Tx.
> ....Arjan...
Schobi
Arjan de Haan
> The closest to what you describe in SVN is probably changelists:
> http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.changelists
> Unless I misunderstood, that is.
>
That's pretty close, yes. Someone mentioned it today to me too. It looks
promising. Thanks for the link.
...Arjan...
Hendrik Schober
I never used it, though. Usually I have several working
copies on my HD where I can work simultaneously. After
all, SVN's changelists only help if several changes work
on disjunct sets of files. And somehow too often I end up
having to fix several things at once in the same files... :)
> ....Arjan...
Schobi
Jorgen Grahn
...
> I never used it, though. Usually I have several working
> copies on my HD where I can work simultaneously. After
> all, SVN's changelists only help if several changes work
> on disjunct sets of files. And somehow too often I end up
> having to fix several things at once in the same files... :)
I don't use SVN, but the principle is the same in CVS and ClearCase
... I don't find myself in that situation very often; I can usually
check in all changes and describe them as "did this single thing".
The exceptions are when I am working on something and:
- find unrelated grammar or spelling errors (not worth keeping
as separate changes)
- work without repository access (fairly rare; one solution is multiple
workspaces like you mentioned, if the separate changesets have no
dependencies)
- it is early in the project and nothing is yet working (little
reason to separate the changes)
marlow...@googlemail.com
> Arjan de Haan wrote:
> > Hendrik Schober wrote:
> >> The closest to what you describe in SVN is probably changelists:
> >> Unless I misunderstood, that is.
>
> > That's pretty close, yes. Someone mentioned it today to me too. It looks
> > promising. Thanks for the link.
>
> I never used it, though. Usually I have several working
> copies on my HD where I can work simultaneously. After
> all, SVN's changelists only help if several changes work
> on disjunct sets of files. And somehow too often I end up
> having to fix several things at once in the same files... :)
>
> > ....Arjan...
>
> Schobi
Good choices have been mentioned, I'll add perforce to the list even
though it's proprietary. But the most important thing is to stop using
VSS. See http://www.andrewpetermarlow.co.uk/subversion_scc.html
-Andrew Marlow