On 10/4/06, Ryan Schmidt <subversion-2006d@ryandesign.com> wrote:
>
> On Oct 4, 2006, at 20:13, Steve Martin wrote:
>
> > The last contract I was on, we needed an SCM system. I chose CVS,
> > but the developers decided they wanted to try Subversion.
> >
> > So.. we went with subversion. We went with it, *I* dealt with the
> > head aches, the fact that you can't make a simple commit without
> > changing the version # of the entire repo,
> > and so many of the other complaints / issues I've seen on this list.
> >
> > My new job also required an SCM system, and I set CVS up in half
> > the time, without having to explain why the rev # of the entire
> > repo and every file checked out changes during a commit, no
> > "malformed this or that" errors,
> > no issues with apache authentication, no issues with svn -d, nothing.
> >
> > It worked perfectly like CVS always has, which subversion never has
> > for me or a lot of the others on this list.
> >
> > So... all I'm asking is, what is so great about subversion that
> > would make people want to give up the tried and tested SCM system,
> > for something that seemingly has so many problems?
> >
> > And the previous SVN setup was on RHEL 4, and the current CVS setup
> > is on RHEL 4. I'm certainly not a noob to this kind of thing, and
> > did RTFM before setting subversion up, but it never worked for us
> > like advertised, while CVS worked exactly like CVS always does...
> > import a file, only IT'S rev changes, not everything in that dir or
> > the entire repo...
>
> Why Subversion? Because the problems you mention should not occur,
> and/or are not problems. I have never used CVS. I set up a Subversion
> repository 18 months ago for our company of 10 developers. No
> problems. No "malformed this or that" errors; probably something
> misconfigured in your setup. I don't know what you mean with "svn -d"
> problems. I don't know what Apache authentication problems you're
> talking about either. We serve our repository through Apache 2 and
> authenticate through Apache to our LDAP server. Works great.
>
> As to the revision number of the repository, it sounds like you're
> attaching a meaning to that number which in Subversion is not
> present. In CVS, each file has a revision number. In Subversion, the
> repository has a revision number. The number is exactly the number of
> commits that have occurred in the repository. Nothing more.
>
> This and other topics are addressed in the section of the Subversion
> book for CVS converts. As I haven't used CVS I can't evaluate its
> effectiveness, but maybe it will help in one way or another.
>
> http://svnbook.red-bean.com/en/1.2/svn.forcvs.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
There are two main reasons why I believe Subversion is far better:
-- Version tree changes (directories included!!!)
-- Much easier interface. With cvs you have to give 3 or 4 options
for every single thing you want to do! Or so it seems. 'cvs -nq
update' vs 'svn st' . And do not get me started on the checkout!
Global revisions. Yes, if you come from a CVS (really RCS) world than
it is a complete rethink. But in reality it buys you a lot and you
lose nothing (in terms of information, maybe in the *presentation* of
that information).
* logs
With global revisions you can do a 'svn log' on a directory and the
output makes sense. It isn't just a recursive dump of all the
individual files. You have a time-ordered set of all the logs that
apply to that directory and it's children. You can actually follow
development process.
* Change sets
Talden mentioned a desire to have 'revision aliases', but what he is
describing is 'tags' which you can implement as copies to a 'tags'
directory. However, I think the functionality that he is really
meaning is the ability to pick some arbitrary point in history (even
if you did not have the forethought to 'tag' that set) and pick up a
particular version of the code. Without the change set concept you
cannot do this efficently. In Subversion you can look through the log
output for a particular day, then look around at the commits made
during that day to find the SET of changes you are interested in. In
CVS you get to go figure that out for every single file that MIGHT be
part of the set.
I find that it helps to think of the revs in subversion has just being
a reference, do not attach any more meaning to them than that. Really
file revs in CVS are the same way, you are just used to that.
Personally, the only additional information that I can think of that
individual file revs gives you is a 'feeling' of how much that file
has been changed. 1.100 is hacked on much more than 1.3. But if you
want that info in subversion just dump the log message...it will only
show you those that pertain to that file. Of course I can understand
the discomfort if you have multiple independent projects in the same
repository...but in that case it should be a different repository.
Branches and tags as copies. Here is where your background in CVS
really restricts your thinking (IMHO). If your SCM tool has a special
meaning attached to 'branching' and 'tagging', then you must always
determine which is right for a particular action. Is a release a
tagging operation or a branching operation? What about development
releases? You end up saying things like "I'll tag that dev release
for you" or "I'll branch that product release". Even though the
standard 'trunk', 'branches', and 'tags' model in subversion promotes
the same thought process, you aren't limited to it. For instance in
my work we have (as top-level)
'master'
'releases'
'versions'
'source_disk'
'tasks'
Now we don't have to think about whether creating a new source_disk is
a branch action or tag action...we just stick it in the 'source_disk'
directory. And the same is true for the other directories, just copy
them to where they go.
I am sorry that you are having so much difficulty. Like other's have
already said, I have not run into any of those issues myself, but I am
sure they can be resolved. So many people would not be using a tool
that doesn't work. The only complaint that I have with subversion is
that the perl API is way out-of-date (like mostly 1.0.x). With a
commercial product you would expect a 1.4 release would be 1.4 all the
way through. However, with a commercial product you also could not
fill in the holes yourself (which I have done a couple of times).
Don't give up yet, there are major benefits! (DIRECTORIES!)
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 5 05:37:20 2006