You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Martin <sm...@gmail.com> on 2006/10/05 01:13:12 UTC
why subversion?
I'm just curious.. not meant to be a flame/troll etc.
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...
love,
me
Re: why subversion?
Posted by Matt Sickler <cr...@gmail.com>.
The repository having a revision number rather than each file is a *Feature*
of svn, not a bug.
On 10/4/06, Steve Martin <sm...@gmail.com> wrote:
>
> I'm just curious.. not meant to be a flame/troll etc.
>
> 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...
>
>
> love,
>
> me
>
Re: why subversion?
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/4/06, Talden <ta...@gmail.com> wrote:
> Thanks Troy, that helps convince me that I have a good handle on the
> benefits of Subversion as well. I haven't played with better security
> and I think that linking it to our LDAP would be quite popular.
>
> > 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).
>
> Agreed, this isn't a bug, it is definitely a feature that works
> well... The only cost I see here is the loss of visibility as to which
> files are the most busy. It's important to understand that a file
> doesn't have a new revision, the repository does - and the working
> copy number is just an indicator of how up to date you are.
>
> > 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.
>
> I use the logs more in my testing of subversion than I ever would in
> CVS just because of the clarity. Atomic renames would help here too
> as would the ability to log the 'futures' of a file/folder - what
> changes have been made, where has it been copied to and how was its
> content modified there.
>
> > 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 still think that referring to revision numbers can be cumbersome.
> Using tags is part of the solution for content management but not
> repository management. 'this' revision is the one we were at before
> we did that upgrade or major repository cleanup. It certainly doesn't
> work without changesets.
>
> But yes I definitely didn't stress the benfits of the more flexible
> nature of copying for tags and branches - other than wishing there was
> an explicit means of locking a URL (and sub URLs) from checkins
> without resorting to obscure hooks I think the mechanism works
> brilliantly.
>
> Easy things
> - creating AND removing branches (close branches once they're done)
> - being able to organise tags and branches into logical groups
>
> I've considered
> tags/releases/ -- tags on release, this stuff's in the wild and must
> be supported.
> tags/milestones/ -- tags of completed milestones in development
> branches/dev -- development branches that may make it into trunk
> branches/maintenance/ -- maintainence work for making point releases.
>
> > 'master'
> > 'releases'
> > 'versions'
> > 'source_disk'
> > 'tasks'
>
> very close to the combination I came up with by the sounds of it.
>
> Definitely don't give up, I'll continue to work up a case for
> migration because my experimentation already yielded improvements to
> our process that CVS can't offer without being a burden.
>
> I haven't actually tested the CVS migration tool yet, that sounds like
> fun... Any comments on how easy/hard this process is?
>
> --
> Talden
>
I used the CVS migration tool to convert a RCS repository to
Subversion (RCS->CVS is a trivial move of files up a directory level).
I had some issues with it bailing out because of some formating
issues. There was one file that I ended up just deleting out all the
diff from the RCS file because it wasn't worth the effort to actually
fix it (it was a dead file). I also had to modify the script to just
ignore a revision '1', as that is not a valid RCS revision but it
somehow picked it out of the file. Once I got those things ironed out
then it worked smashingly!
If you using CVS proper you most likely won't have the same issues
because these particular RCS files span more than 10 years and no
fewer than 3 different OSes...they were bound to accumulate some
cruft.
The only real problem I had with the tool was the repository size and
number of revisions. By the time it was all said and done my ~1GB
repository was 2GB with >60000 revs! FSFS just dragged to the point
it was unusable so I had to go with BDB (just too many files in the db
directory). I just read a possible explanation of my repo size
exploding on the dev list: my directory structure. Apparently the
mechanism for storing the directory stuff in the repo is pretty
wasteful and I have a pretty convoluted hierarchy.
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
Re: why subversion?
Posted by Talden <ta...@gmail.com>.
Thanks Troy, that helps convince me that I have a good handle on the
benefits of Subversion as well. I haven't played with better security
and I think that linking it to our LDAP would be quite popular.
> 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).
Agreed, this isn't a bug, it is definitely a feature that works
well... The only cost I see here is the loss of visibility as to which
files are the most busy. It's important to understand that a file
doesn't have a new revision, the repository does - and the working
copy number is just an indicator of how up to date you are.
> 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.
I use the logs more in my testing of subversion than I ever would in
CVS just because of the clarity. Atomic renames would help here too
as would the ability to log the 'futures' of a file/folder - what
changes have been made, where has it been copied to and how was its
content modified there.
> 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 still think that referring to revision numbers can be cumbersome.
Using tags is part of the solution for content management but not
repository management. 'this' revision is the one we were at before
we did that upgrade or major repository cleanup. It certainly doesn't
work without changesets.
But yes I definitely didn't stress the benfits of the more flexible
nature of copying for tags and branches - other than wishing there was
an explicit means of locking a URL (and sub URLs) from checkins
without resorting to obscure hooks I think the mechanism works
brilliantly.
Easy things
- creating AND removing branches (close branches once they're done)
- being able to organise tags and branches into logical groups
I've considered
tags/releases/ -- tags on release, this stuff's in the wild and must
be supported.
tags/milestones/ -- tags of completed milestones in development
branches/dev -- development branches that may make it into trunk
branches/maintenance/ -- maintainence work for making point releases.
> 'master'
> 'releases'
> 'versions'
> 'source_disk'
> 'tasks'
very close to the combination I came up with by the sounds of it.
Definitely don't give up, I'll continue to work up a case for
migration because my experimentation already yielded improvements to
our process that CVS can't offer without being a burden.
I haven't actually tested the CVS migration tool yet, that sounds like
fun... Any comments on how easy/hard this process is?
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/4/06, Ryan Schmidt <su...@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
Re: why subversion?
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
Re: why subversion?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 16, 2006, at 00:29, Thomas Harold wrote:
> Ideally, I'd like a flag where I can tell SVN that I don't want to
> keep pristine copies (in exchange for higher network traffic and a
> higher server load). Either on a folder-by-folder basis (with
> inheritance) or on a file-type basis across a set of folders or the
> entire working copy (or entire repository).
Right; that's this feature request to allow working copies without
the text-base:
http://subversion.tigris.org/issues/show_bug.cgi?id=525
And the related issue of allowing a compressed text-base:
http://subversion.tigris.org/issues/show_bug.cgi?id=908
> Which goes along with your (and others') ideas that some file types
> are best sent over the wire without computing deltas.
That would be a separate issue. Can't find an issue tracker record
for it. The closest thing I found is this, which only relates to
turning off over-the-wire deltas when initially importing files:
http://subversion.tigris.org/issues/show_bug.cgi?id=913
> (The possible downside of not computing deltas depends on whether
> the server attempts a delta in order to store the file. If the
> client doesn't do the work, then it's up to the server to do it.
> Unless the server simply stores a new snapshot in the repository
> which would be the trade-off resulting in larger repositories.)
The server will always compute its own delta, which will usually or
possibly always be a different delta than the one the client sent in.
The client will send a delta against whatever previous revision was
in the working copy. In an FSFS repository, the server will store a
delta against a particular previous revision which is selected using
the skip-deltas algorithm, about which you can read here:
http://svn.collab.net/repos/svn/trunk/notes/skip-deltas
In a BDB repository, the server instead stores the complete head
revision, and redeltifies previous revisions, sort of the other way
round from FSFS.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Thomas Harold <tg...@tgharold.com>.
Talden wrote:
> Things that I've had to wrap my head around and accept as reasonable.
>
> - Pristine copies. Damn that's a lot of diskspace used up. Yeah but
> you can revert extremely cheaply in many cases and you're sending
> diffs in boths directions. Aw hell, realistically disk is cheap
> enough that most non-video-production projects are never going to
> care.
I'm still wrestling with the pristine copy space issue in the migration
from SOS+VSS to SVN. Mostly for my photography archives which are
15-20GB at the moment with multi-megabyte files. Having to use up
30-40GB for 15-20GB of files seems a bit wasteful. (It impacts backup
sizes, NTFSClone image sizes and other situations.)
I think I can mitigate a lot of it by mapping a windows drive to a
WebDAV version of the repository.
Alternately, I'm considering making more use of "svn import" / "svn
export" for the local copy on my laptop drive.
Ideally, I'd like a flag where I can tell SVN that I don't want to keep
pristine copies (in exchange for higher network traffic and a higher
server load). Either on a folder-by-folder basis (with inheritance) or
on a file-type basis across a set of folders or the entire working copy
(or entire repository). Which goes along with your (and others') ideas
that some file types are best sent over the wire without computing deltas.
(The possible downside of not computing deltas depends on whether the
server attempts a delta in order to store the file. If the client
doesn't do the work, then it's up to the server to do it. Unless the
server simply stores a new snapshot in the repository which would be the
trade-off resulting in larger repositories.)
I understand and agree with why SVN keeps a local pristine copy... I'm
just happy that perpendicular-recording technology is now available so I
can buy that 160GB 2.5" drive for my laptop...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Talden <ta...@gmail.com>.
On 10/5/06, Steve Martin <sm...@gmail.com> wrote:
> [EDITED]
> 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...
Having used CVS for a long time myself I'm surprised you haven't met
some of the CVS bugbears.
- non-atomic commits (how's that broken build workin' for ya)
- unversioned directories
- untracked renames, copies and moves
- very slow tagging and branching.
My office is on a different continent to our repository and one thing
CVS isn't, is efficient in it's network usage.
That said, we're still using CVS. I've been unable to sell the team
(and myself in all honesty) on the immediacy of our need to move to
Subversion.
Some things I'd like to see (and some are coming).
- Merge-tracking
- revision aliases (it's easier to remember 'that_day_in_may' than r18357).
- Forward tracking of revisions from a URL@revision. I want to see
where filex was moved to and what changes were made. It's not enough
to just see where it was moved from.
- atomic renames.
- ability to configure the server and client not to compute diffs
based on mime-type. Some types just produce awful diffs and for the
minute gains in space/transmission the cost of computation is
prohibitive.
Things that I've had to wrap my head around and accept as reasonable.
- A repository revision # is a good thing. It immediately prevents a
check-in that might break the build purely because someone checked in
an incompatible change since you tested.
- Branching and tagging as folder copies. This one's tougher since
it's a mixed bag, it munges the namespace with folders that aren't
real development artifacts (trunk, branches, tags, etc). I wonder if
this wasn't the best decision (probably the simplest though). You
can't argue with the fast copies, and deletable branches and tags.
- Pristine copies. Damn that's a lot of diskspace used up. Yeah but
you can revert extremely cheaply in many cases and you're sending
diffs in boths directions. Aw hell, realistically disk is cheap
enough that most non-video-production projects are never going to
care.
There's better, more granular security as well. I'm sure there's
plenty I've missed.
We'll be moving and I believe it's not if but when. And that when is
probably soon after merge-tracking is complete and someone else has
walked the mine-field of its first release.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 5 Oct 2006, at 02:13, Steve Martin wrote:
> I'm just curious.. not meant to be a flame/troll etc.
>
> 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.
Interestingly, after many years of using Subversion, I'm working with
a customer who has set up a source code repository with CVS
(unfortunately, it was a fait accompli before I got here).
There's another developer on the project who has used Subversion in
the past but not CVS. Explaining to him how all the files have
different revision numbers when they represent a logical single state
of the source code has proved problematic. He nearly resigned when
he found out that moves, copies and directories are not versioned and
neither is the creation or moving of a tag.
And I can't repeat what he said when he added and committed a graphic
without specifying -kb (i.e. treat as binary, not text) and found out
that that checking it out to a Windows box corrupted it.
A lot of software usability is what you are used to. In the old Win
3.1 days I remember the arguments (wars) between the MS Excel camp
and the Lotus 123 camp. I was firmly on the side of Excel until I
was forced by a project to use Lotus 123 for a while.
Many of the problems you list are really symptoms of "what you are
used to". On the other hand, some (not all) of the problems that my
colleague has really are indicative of missing functionality in CVS.
>
> 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...
>
>
> love,
>
> me
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Pierrick LE GALL <pl...@talend.com>.
"Bruce Thompson" <br...@otherother.com> writes:
> In CVS it is not possible to check the status of a file without
> updating that file [...]
Why not running "cvs update" in dry-run mode? With this workaround you
can see if a file has a new version on the current branch or if you have
a local modification.
$ cvs -nq up
M file1 # localy modified
G file2 # localy modified + new version on repository + successful merge
C file3 # localy modified + new version on repository + conflicting merge
U file4 # new version on repository
A file5 # file to be added in next commit
? file6 # unversionned file
That's not pretty as "svn status --show-updates" can be, but it's very
useful when you can't migrate to Subversion :-)
--
Pierrick LE GALL
R&D engineer at Talend, Open data solution
http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Les Mikesell <le...@gmail.com>.
On Thu, 2006-10-05 at 22:35 -0700, Bruce Thompson wrote:
> I'm somewhat surprised that my favorite feature (and least favorite
> CVS mis-feature) hasn't been mentioned.
>
> In CVS it is not possible to check the status of a file without
> updating that file (possibly merging in changes as well). At the
> office we're stuck in CVS and I am continually bumping into this. All
> I want to know is whether the file is up to date either against
> latest checked in revision or against the last time I updated.
What happens when you run:
cvs status filename
or just
cvs status
in the directory?
CVS is just a _file_ version control program with a concept of
tags as a shorthand notation for a collection of file version
numbers to tie a bunch of file/versions together. If you want
to manage files, CVS does a good job. For example, I have a directory
where I store all my router and switch configs via tftp after
each change and commit to CVS. None of the files have anything
to do with each other and they are never renamed. I don't think
subversion can add any functionality to CVS in this situation and
when I no longer need a file/history I can simply remove it
from the repository. On the other hand if you need a concept
of 'projects' and want to track directory changes and files
that are renamed, subversion has advantages.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Bruce Thompson <br...@otherother.com>.
I'm somewhat surprised that my favorite feature (and least favorite
CVS mis-feature) hasn't been mentioned.
In CVS it is not possible to check the status of a file without
updating that file (possibly merging in changes as well). At the
office we're stuck in CVS and I am continually bumping into this. All
I want to know is whether the file is up to date either against
latest checked in revision or against the last time I updated.
Status checking and updates are different concepts! CVS makes me do
both whether I want to or not where Subversion lets me decide which I
want to do.
For me that's worth the price of admission right there.
Cheers!
Bruce.
On Oct 5, 2006, at 2:01 PM, Mark wrote:
> Having admined 700+ CVS projects for the past 2 years, I am thoroughly
> sick and tired of CVS. On top of all the aforementioned CVS bugaboos,
> I have to run crons every hour to keep the permissions/ownerships
> straight.
>
> Admining SVN is a breeze compared to CVS. Using it is great, too. It
> is so easy to see the branches and tags since they are directories.
> It makes so much more sense that the whole repository is versioned
> instead of each file individually.
>
> You mentioned you are on RHEL. Personally, I ripped out all the SVN
> related rpms (neon, apr, apr-uril, httpd) and compiled and installed
> the latest versions myself. Did you use the RHEL rpms?
>
> I've had repos on svn now for a couple months. I have some tiny ones,
> and I have a couple that are about 5 gig - no issues.
>
> On 10/4/06, Steve Martin <sm...@gmail.com> wrote:
>> I'm just curious.. not meant to be a flame/troll etc.
>>
>> 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...
>>
>>
>> love,
>>
>> me
>>
>
>
> --
> Mark
> "Blessed is he who finds happiness in his own foolishness, for he will
> always be happy."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
> !DSPAM:452572a2172564364311965!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: why subversion?
Posted by Mark <ma...@mitsein.net>.
Having admined 700+ CVS projects for the past 2 years, I am thoroughly
sick and tired of CVS. On top of all the aforementioned CVS bugaboos,
I have to run crons every hour to keep the permissions/ownerships
straight.
Admining SVN is a breeze compared to CVS. Using it is great, too. It
is so easy to see the branches and tags since they are directories.
It makes so much more sense that the whole repository is versioned
instead of each file individually.
You mentioned you are on RHEL. Personally, I ripped out all the SVN
related rpms (neon, apr, apr-uril, httpd) and compiled and installed
the latest versions myself. Did you use the RHEL rpms?
I've had repos on svn now for a couple months. I have some tiny ones,
and I have a couple that are about 5 gig - no issues.
On 10/4/06, Steve Martin <sm...@gmail.com> wrote:
> I'm just curious.. not meant to be a flame/troll etc.
>
> 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...
>
>
> love,
>
> me
>
--
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: why subversion?
Posted by "Reedick, Andrew" <An...@BellSouth.com>.
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...
As a CM (Configuration Management) weenie, I loathe CVS because of how
slow the branching and labeling is. At my last company, it took close
to an hour to branch/label the code, which made effective CM
impractical. With subversion I can branch and label in under a second
for a tree containing thousands of files.
Subversion also has directory versioning, which means you can now record
and *undo* file renames or moves. Atomic commits are very nice. It can
also handle empty directories. Subversion treats every file as binary,
so none of that -kb nonsense. There are no standard procedures that
involve hacking the back end repository. CVS is becoming more and more
out-dated and needs to go away.
The biggest difficulty with Subversion is the paradigm shift. Coming
from 7 years of ClearCase, the One Revision Number thing took a lot of
getting used to. That and the lack of a "proper" version tree.
Generally speaking, as a CM weenie, and after a bit of time, I find
Subversion's tree based paradigm to be a great improvement over the
file-centric paradigm started with RCS. It just takes a bit of getting
used to.
The biggest flaw with Subversion right now is the lack of proper merge
tracking.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org