You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Eric B." <eb...@hotmail.com> on 2009/09/09 14:43:04 UTC
Move from CVSNT to SVN?
Hi,
I'm considering a switch from CVSNT to SVN and am looking for feedback from
people who have made the switch in the past. Are you happy with your new
choice? Does SVN allow you to be more productive than CVS? What prompted
the move? What features are you able to use with SVN that you didn't have
with CVS? From the flip side, are there reasons you regret making the
change? Are there things in SVN that are more complicated or difficult to
acheive than CVS? Or are some tasks with SVN more error-prone?
I know that a great portion of the OSS community has switched to svn
(apache, sourceforge, etc), so I'm trying to find out "why". I know that
SVN allows for directory revisioning, but I am assuming that there must be
more than just that to promote such a large change over.
I'm not trying to start a war as to which solution is "better"; rather just
looking for feedback from experienced users who have made the transition and
recommendations or warnings of things to be aware of prior to making a
decision.
I have a large CVS repository from 10yrs of code that I would be moving
over, so it isn't a decision that I'm going to be making lightly.
Thanks for any insight!
Eric
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393030
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Johan Corveleyn!
> * You can confuse SVN's working copy by doing too much renaming/moving at
> once. For example see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3429 and
> http://subversion.tigris.org/issues/show_bug.cgi?id=3474. Hopefully this
> will be improved when 1.7 gets out (which includes a rewrite of the
> working-copy stuff). For now, you just need to be aware of the limitations
> and be careful (committing in between helps)
This is deserve an emphasis.
If you are doing a renaming or moving in your project, it'd be a very good
idea to either 1. do renames/moves directly in repository or 2. commit each
separate rename/move. This way you are much less likely encounter superserious
issues with conflicting/ambiguous names in future.
> But all in all, I think the advantages definitely outweigh the negative
> points (and since it's actively developed, and has a very active user
> community, I trust that it will keep on improving).
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 11.09.2009, <19:43>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393641
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Move from CVSNT to SVN?
Posted by Johan Corveleyn <jo...@uz.kuleuven.ac.be>.
Just adding my .02:
We migrated from CVS(notNT) to SVN half a year ago. I agree with most of the things already said (advantages like atomic commits, renames/moves, active development, a lot of great features, ...). It's usually a very good "upgrade".
But to balance things a little, I'm adding some more critical sounds:
- SVN is slower than CVS for "log" and "annotate" for a particular file. This is understandable given the difference in architecture (CVS has all the information in that single ,v file; SVN has to plough through a huge pile of revisions to get the info). Usually it will still be ok, and you won't notice the difference. But we have some really horrible edge cases here: a 2MB xml file with 6000 revisions (and counting).
* Log: 5 seconds with CVS, 4 minutes with SVN
* Annotate: 17 seconds with CVS, connection timeout after 50 minutes with SVN
As I said, this is an extreme case. For normal source files with maybe a couple hundred revisions it's fine.
- Unlike with CVS, there is no easy way in SVN to see which tags (or branches) are "attached" to a particular version of a file. You can see in a tag or branch where the file was "copied from", but you can't see in trunk where a file was "copied to".
- As you hinted yourself, the rename/move support is limited. Of course it's already a huge step forward from CVS (no rename/move support). But there are some limitations (which can come up regularly when you tend to refactor often, rename and move things around, ...):
* There is the "tree conflict" thing (as someone else already commented). I.e., when moving/renaming, tree conflicts will happen (on merging branches, or simply when someone else commits renames/moves, while you were modifying the files locally or something like that). As of SVN 1.6, tree conflicts are detected (which is great). But there is no built in tooling to help you resolve them.
* You can confuse SVN's working copy by doing too much renaming/moving at once. For example see http://subversion.tigris.org/issues/show_bug.cgi?id=3429 and http://subversion.tigris.org/issues/show_bug.cgi?id=3474. Hopefully this will be improved when 1.7 gets out (which includes a rewrite of the working-copy stuff). For now, you just need to be aware of the limitations and be careful (committing in between helps)
But all in all, I think the advantages definitely outweigh the negative points (and since it's actively developed, and has a very active user community, I trust that it will keep on improving).
Regards,
Johan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393573
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, David Weintraub!
> We moved from CVS to Subversion, and we did it because I liked the features
> in Subversion that were completely missing in CVS. Subversion can use Apache
> as a protocol which means I can use LDAP that connects to my Windows server.
> Before, we were using pserver and I had to manually give everyone an
> account. Now, when a developer gets their Windows account, they have
> Subversion access.
CVSNT can use sspi authorization (I've been using it for years).
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 11.09.2009, <11:54>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393554
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by "Eric B." <eb...@hotmail.com>.
Hi David,
Thanks for the feedback. I know that svn has all but replaced CVS in the
last years. I know that the CVSNT developers (March-Hare) have been
actively working on it, as well as a new replacement that is supposed to
support all stnadard clients (CVS, SVN, etc), but development seems to be
quite slow compared to svn.
Hence the reason to start to question if sticking around for something like
that is worthwhile, or if it is worth the effort to switch to svn.
Thanks for the insights!
Eric
"David Weintraub" <qa...@gmail.com> wrote in message
news:e18234670909102021t183e03a6ye684c66a2031cfa3@mail.gmail.com...
Sorry I'm late to the conversation, but here's my take:
We moved from CVS to Subversion, and we did it because I liked the
features in Subversion that were completely missing in CVS. Subversion can
use Apache as a protocol which means I can use LDAP that connects to my
Windows server. Before, we were using pserver and I had to manually give
everyone an account. Now, when a developer gets their Windows account, they
have Subversion access.
Subversion handles our end-of-line issues. In CVS, the client was suppose
to do this, but we always ended up with mixed EOL styles. In Subversion, I
can make sure shell scripts have the UNIX EOL style set. I can also use
hooks to lock branches when they aren't in use (it's much harder to do in
CVS), and developers can easily find their change set and back out their
changes.
We do continuous builds, and CVS taking 30 to 40 minutes to label was
hurting our ability to build after every change. Subversion can tag a build
in less than a second. What use to take 50 minutes now can be done in 10
minutes. And, really I don't even need to create a tag if I know the
Subversion revision number.
There's little things like a developer being able to see a list of
branches and tags without having to examine every file in the repository.
What use to take 20 minutes in CVS can be done in a few seconds in
Subversion.
Subversion and CVS use similar workflows, so they're fairly compatible in
that area. We didn't have to completely redo our entire build infrastructure
because we changed from CVS to Subversion. Something that you might have to
do if you moved to say ClearCase.
To me, if you're using CVS, you might as well upgrade to Subversion. CVS
has had no active development in the last decade. Subversion has replaced
CVS in that respect.
On Wed, Sep 9, 2009 at 10:43 AM, Eric B. <eb...@hotmail.com> wrote:
Hi,
I'm considering a switch from CVSNT to SVN and am looking for feedback
from
people who have made the switch in the past. Are you happy with your
new
choice? Does SVN allow you to be more productive than CVS? What
prompted
the move? What features are you able to use with SVN that you didn't
have
with CVS? From the flip side, are there reasons you regret making the
change? Are there things in SVN that are more complicated or difficult
to
acheive than CVS? Or are some tasks with SVN more error-prone?
I know that a great portion of the OSS community has switched to svn
(apache, sourceforge, etc), so I'm trying to find out "why". I know
that
SVN allows for directory revisioning, but I am assuming that there must
be
more than just that to promote such a large change over.
I'm not trying to start a war as to which solution is "better"; rather
just
looking for feedback from experienced users who have made the transition
and
recommendations or warnings of things to be aware of prior to making a
decision.
I have a large CVS repository from 10yrs of code that I would be moving
over, so it isn't a decision that I'm going to be making lightly.
Thanks for any insight!
Eric
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393030
To unsubscribe from this discussion, e-mail:
[users-unsubscribe@subversion.tigris.org].
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394637
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by David Weintraub <qa...@gmail.com>.
Sorry I'm late to the conversation, but here's my take:
We moved from CVS to Subversion, and we did it because I liked the features
in Subversion that were completely missing in CVS. Subversion can use Apache
as a protocol which means I can use LDAP that connects to my Windows server.
Before, we were using pserver and I had to manually give everyone an
account. Now, when a developer gets their Windows account, they have
Subversion access.
Subversion handles our end-of-line issues. In CVS, the client was suppose to
do this, but we always ended up with mixed EOL styles. In Subversion, I can
make sure shell scripts have the UNIX EOL style set. I can also use hooks to
lock branches when they aren't in use (it's much harder to do in CVS), and
developers can easily find their change set and back out their changes.
We do continuous builds, and CVS taking 30 to 40 minutes to label was
hurting our ability to build after every change. Subversion can tag a build
in less than a second. What use to take 50 minutes now can be done in 10
minutes. And, really I don't even need to create a tag if I know the
Subversion revision number.
There's little things like a developer being able to see a list of branches
and tags without having to examine every file in the repository. What use to
take 20 minutes in CVS can be done in a few seconds in Subversion.
Subversion and CVS use similar workflows, so they're fairly compatible in
that area. We didn't have to completely redo our entire build infrastructure
because we changed from CVS to Subversion. Something that you might have to
do if you moved to say ClearCase.
To me, if you're using CVS, you might as well upgrade to Subversion. CVS has
had no active development in the last decade. Subversion has replaced CVS in
that respect.
On Wed, Sep 9, 2009 at 10:43 AM, Eric B. <eb...@hotmail.com> wrote:
> Hi,
>
> I'm considering a switch from CVSNT to SVN and am looking for feedback from
> people who have made the switch in the past. Are you happy with your new
> choice? Does SVN allow you to be more productive than CVS? What prompted
> the move? What features are you able to use with SVN that you didn't have
> with CVS? From the flip side, are there reasons you regret making the
> change? Are there things in SVN that are more complicated or difficult to
> acheive than CVS? Or are some tasks with SVN more error-prone?
>
> I know that a great portion of the OSS community has switched to svn
> (apache, sourceforge, etc), so I'm trying to find out "why". I know that
> SVN allows for directory revisioning, but I am assuming that there must be
> more than just that to promote such a large change over.
>
> I'm not trying to start a war as to which solution is "better"; rather just
> looking for feedback from experienced users who have made the transition
> and
> recommendations or warnings of things to be aware of prior to making a
> decision.
>
> I have a large CVS repository from 10yrs of code that I would be moving
> over, so it isn't a decision that I'm going to be making lightly.
>
> Thanks for any insight!
>
> Eric
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393030
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393502
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Multiple teams + Different Build Options + One Repository?
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Shaun Pinney!
> Thanks for the response! Sorry, maybe I could have chosen the subject line
> better :)
It's not the subject line, it's the "Reply" button you hit, instead of "New
message".
> I like the single script idea but, unfortunately, we cannot auto-configure
> the correct team settings based solely on the build environment info. So
> maybe branching can provide the solution. Can you let me know if I
> understand your idea correctly?
Yes, something like this I've had in mind.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 11.09.2009, <11:50>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393551
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Multiple teams + Different Build Options + One Repository?
Posted by Shaun Pinney <sh...@bil.konicaminolta.us>.
Hi Andrey,
Thanks for the response! Sorry, maybe I could have chosen the subject line
better :)
I like the single script idea but, unfortunately, we cannot auto-configure
the correct team settings based solely on the build environment info. So
maybe branching can provide the solution. Can you let me know if I
understand your idea correctly?
Say we have our config files, /trunk/foo/buildFoo.bat and
/trunk/foo/h/config.h, and source files in /foo which are built by
buildFoo.bat and which include config.h.
/trunk/foo/buildFoo.bat
/trunk/foo/foo.c
/trunk/foo/foo.h
/trunk/foo/h/config.h
We'd create a branch of buildFoo.bat for each team, modify them to contain
each team's settings, and commit:
/branches/team1/buildFoo.bat
/branches/team1/config.h
/branches/team2/buildFoo.bat
/branches/team2/config.h
/trunk/foo/buildFoo.bat
/trunk/foo/foo.c
/trunk/foo/foo.h
/trunk/foo/h/config.h
Next, I'd imagine if we're creating branches for each team we'd remove
/trunk/foo/buildFoo.bat and /trunk/foo/h/config.h to avoid duplication in
SVN. Before building we'd probably create a new script to copy all
configuration files from "teamN/" to their original locations (to avoid
modifying any Makefiles due to moving files from their original locations
into 'teamN' directories). So the build process would be to checkout, run
the 'team select' script to copy files from "teamN/" to correctly locations,
and then run buildFoo.bat from /trunk/foo/buildFoo.bat, as we currently do.
Also, the sources would still remain in the trunk.
/branches/team1/buildFoo.bat
/branches/team1/config.h
/branches/team2/buildFoo.bat
/branches/team2/config.h
/trunk/foo/foo.c
/trunk/foo/foo.h
/trunk/foo/h/
At first glance, I like a lot about this idea. It gives each team a single
directory to modify every configuration file. It does not require any
Makefile changes, since even though configuration files are moved to new
locations, they are copied to their original locations before building.
That means we do not need to change our current build procedure, other than
to select the desired 'teamN' configuration. Plus, it allows changes from
one team to be viewed by the other with a simple SVN Update (which is what
we want, AFAIK. Could change tomorrow, who knows? :). I've elaborated a
bit beyond your suggestion with the team select script, I know, but does
this seem sane?
Please let me know if I have the right understanding.
Thanks,
Shaun
-----Original Message-----
From: Andrey Repin [mailto:anrdaemon@freemail.ru]
Sent: Thursday, September 10, 2009 6:04 PM
To: Shaun Pinney; users@subversion.tigris.org
Subject: Re: Multiple teams + Different Build Options + One Repository?
Greetings, Shaun Pinney!
> In-Reply-To: <E4...@ryandesign.com>
> References: <h8...@ger.gmane.org>
<7e...@mail.gmail.com>
> <h8...@ger.gmane.org>
<E4...@ryandesign.com>
> Subject: Multiple teams + Different Build Options + One Repository?
First and foremost, please start a new thread by writing a new message
instead
of linking deep into unrelated discussion.
> Quick question. We have an SVN repository and are preparing to provide
> access to another development team. An issue which has come up is our
> software has many build options controlled by a few scattered files and
each
> team needs different build options. Can we provide both teams a way to
> checkout the latest source code, but with different build options? I
think
> we should be able to reduce configuration errors by giving the right build
> options to the right team automatically upon checkout, compared to a
manual
> approach of everyone editing on each checkout. Is there a clever solution
> for this (e.g. svn:externals)? Thanks for any advice!
If you need a different building scripts, I think it would be better to
branch them for every team, unless it is possible to maintain a single
script
that automatically configure itself for the environment it running in.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 11.09.2009, <5:00>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=23
93480
To unsubscribe from this discussion, e-mail:
[users-unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393503
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Multiple teams + Different Build Options + One Repository?
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Shaun Pinney!
> In-Reply-To: <E4...@ryandesign.com>
> References: <h8...@ger.gmane.org> <7e...@mail.gmail.com>
> <h8...@ger.gmane.org> <E4...@ryandesign.com>
> Subject: Multiple teams + Different Build Options + One Repository?
First and foremost, please start a new thread by writing a new message instead
of linking deep into unrelated discussion.
> Quick question. We have an SVN repository and are preparing to provide
> access to another development team. An issue which has come up is our
> software has many build options controlled by a few scattered files and each
> team needs different build options. Can we provide both teams a way to
> checkout the latest source code, but with different build options? I think
> we should be able to reduce configuration errors by giving the right build
> options to the right team automatically upon checkout, compared to a manual
> approach of everyone editing on each checkout. Is there a clever solution
> for this (e.g. svn:externals)? Thanks for any advice!
If you need a different building scripts, I think it would be better to
branch them for every team, unless it is possible to maintain a single script
that automatically configure itself for the environment it running in.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 11.09.2009, <5:00>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393480
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Multiple teams + Different Build Options + One Repository?
Posted by Shaun Pinney <sh...@bil.konicaminolta.us>.
Hello all,
Quick question. We have an SVN repository and are preparing to provide
access to another development team. An issue which has come up is our
software has many build options controlled by a few scattered files and each
team needs different build options. Can we provide both teams a way to
checkout the latest source code, but with different build options? I think
we should be able to reduce configuration errors by giving the right build
options to the right team automatically upon checkout, compared to a manual
approach of everyone editing on each checkout. Is there a clever solution
for this (e.g. svn:externals)? Thanks for any advice!
Best,
Shaun
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393468
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 10, 2009, at 10:19, Eric B. wrote:
> With respect to the repository, I am a little confused about a few
> things. I know that SVN was originally designed to run off a db.
> However, I know it now does flat files as well. Is the flat file
> structure not akin to a CVS repository? Has there been any further
> progress or development to support DBs other than BDB? Do you know
> if there is a particular reason why BDB was chosen vs something like
> MySQL?
A Subversion repository is stored in a database. In Subversion 1.0 and
earlier, that was always a BerkeleyDB database. In Subversion 1.1, it
became possible to use a flat-file database instead. This flat-file
database format is called FSFS and was designed especially for use by
Subversion to work around some of the issues that existed when using
BDB with Subversion. FSFS became the default for new repositories in
Subversion 1.2 and still is today, and works great. No other backend
storage options are available. What advantage do you believe would be
gained by using another backend such as MySQL?
The FSFS Subversion repository storage format is not like the CVS
repository storage format. In CVS, there is one database file per
versioned file (each containing many revisions of a single versioned
file). But in Subversion's FSFS, there are two files per revision (one
containing the differences to the contents of all versioned files
affected by the revision, and another containing the properties of all
versioned files and directories affected by the revision).
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393451
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by "Eric B." <eb...@hotmail.com>.
Wow - thanks for the thorough writeup. It definitely helps me a little. I
can understand a lot of the points; the "Attic" is probably one thing that
drives me nuts in CVS. I find it incredibly hard to ressurect and to see
files in the Attic, although, in theory, it should be relatively easy.
Browsing the Attic as well is a task in frustration alone.
The concept of Atomic commits is really amazing, especially if you work in
large dev teams that cannot easily communicate with each other and who are
constantly updating their sandboxes. However, in practice, I have to say I
haven't really found the need for Atomicity that lacking in CVS.
Re: Move from CVSNT to SVN?
Posted by "Michael P. Reilly" <ar...@gmail.com>.
I won't say from a CVSNT, but from a CVS viewpoint, there are a large number
of reasons. Here are but a few.
1. The 'Attic' - trying to handle moving/renaming files, creating files
on a branch, deleting files from the repository.
2. You already mentioned versioned directories.
3. Searching a repository for one commit that happened last week (can't
always rely on cvs+history), especially including a large number of
directories.
4. Atomic commits - probably the #1 reason developers have claimed a
desire to switch in my experience (but probably not their biggest pet-peeve)
5. Conflict resolution - more options when conflicts are found and how to
handle them; I may not want the file with the tokens in them, so Subversion
supplies instances of the local copy, the branch copies and the merged copy.
6. Deltas of binary files - all files are stored as delta'ed files,
including binary files, not just text files; this *can* be a space saver
on the repository side (depending on how much has changed).
7. Offline support and better network bandwidth - Subversion has a
philosophy that disk space is cheap and bandwidth is expensive: a copy of
your checkout is kept on disk to help speed up operations like svn+diff,
svn+status, svn+revert. Also, since there is already a copy on disk of what
you first checked out, the system knows exactly what you changed and can
sent only those changes instead of the entire file (something that CVS does
only on some files).
8. Transactions - not the same as atomic commits, CVS has no notion of a
changeset. Even if you perform a commit at the same time, the only thing
binding the changes to the different versioned files together is the comment
string and the relative time the commits are made. With Subversion, there
is a single commit entry made that includes all files. Many managers find
this very valuable. This can be simulated with 3rd-party tools in CVS.
9. Repository moves - when a repository server needs to move (it does
happen), developers either need to check in all their code or each CVS/Root
and (depending on the release of CVS) each CVS/Repository file in their work
areas will need to be updated - this could be tens of thousands of files per
developer: 1 or 2 per directory for each checkout. In Subversion, there is
a command to tell the workspace to point to the new server and the workspace
does not need to change.
10. Hot backups - since Subversion is a database, there is the internal
concept of locking the Subversion database to take 'hotcopy' backups which
will take a copy of the repository, ensuring no changes could be made, so
you can safely backup the copy. This is for HEAVY use Subversion
repositories. Ones that get light or no use at night would have no problems
being backed up directly (the same as CVS).
11. I've done a little performance testing on repositories of ~500k
revisions. I saw no degradation in the performance. If you have ten years
of checkins, then you will easily be getting up into that range and
performance should be a consideration for you.
There are some drawbacks to Subversion as well.
1. The 'branches', 'tags', 'trunk' structure is not typical of a version
control system and a little hard for some developers/users to get used to:
'directories as branches?' For some projects where I know there will never
be any divergent development or tagging, then I sometimes forgo the whole
structure and just have a single directory for them... but that has usually
been with marketing types.
2. Revision mumbering scheme is also difficult for some developers/users
to get used to; I like to explain it as layers of onion paper being laid on
top of each other in mechanical drawings, but each looking specific
time-slices in the repository.
3. CVS will honor checkouts in subdirectories, but Subversion will say
that the subdirectory is not part of the current working copy. This is
supposedly to not confuse URLs and revisions and to force the use of
svn:externals.
4. Subversion uses a database and CVS used flat files which made 'fixing'
CVS much easier. However, in the last four years of managing dozens of
large Subversion repositories through power failures and server crashes, I
haven't really had to 'fix' a Subversion repository.
5. Moving a files/directories between Subversion repositories - goes back
to Subversion using a database. You need to export the data from the
database, possibly changing pathnames, and then importing the data into the
new database. There are great tools to do things, but it helps if you know
good "power tools" as well.
These lists are not exhaustive, even even for me, but gives you some idea of
the pros and cons from one person's experience.
In many ways, both are equivalent, so don't get hung up too much. But one
last thought for you: Subversion was to be the next evolution of a version
control system by CVS's own development team.
HTH,
-Arcege
On Wed, Sep 9, 2009 at 10:43 AM, Eric B. <eb...@hotmail.com> wrote:
> Hi,
>
> I'm considering a switch from CVSNT to SVN and am looking for feedback from
> people who have made the switch in the past. Are you happy with your new
> choice? Does SVN allow you to be more productive than CVS? What prompted
> the move? What features are you able to use with SVN that you didn't have
> with CVS? From the flip side, are there reasons you regret making the
> change? Are there things in SVN that are more complicated or difficult to
> acheive than CVS? Or are some tasks with SVN more error-prone?
>
> I know that a great portion of the OSS community has switched to svn
> (apache, sourceforge, etc), so I'm trying to find out "why". I know that
> SVN allows for directory revisioning, but I am assuming that there must be
> more than just that to promote such a large change over.
>
> I'm not trying to start a war as to which solution is "better"; rather just
> looking for feedback from experienced users who have made the transition
> and
> recommendations or warnings of things to be aware of prior to making a
> decision.
>
> I have a large CVS repository from 10yrs of code that I would be moving
> over, so it isn't a decision that I'm going to be making lightly.
>
> Thanks for any insight!
>
> Eric
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393030
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>
--
There's so many different worlds,
So many different suns.
And we have just one world,
But we live in different ones.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393050
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Lorenz <lo...@yahoo.com>.
Stein Somers wrote:
>Eric B. wrote:
> > Would that [retagging] concept/workflow cause problems in SVN?
>
>I do it in an automated build process, and found it only a bit awkward you
>have to delete the tag before adding it again. In pseudo code:
>
> if (svn info the_tag)
> # tag exists so delete it
> svn del the_tag
> svn copy the_revision the_tag
>
>But I probably just lack the imagination and experience to do it in a single
>transaction.
svnmucc rm the_tag cp revision the_revision the_tag
--
Lorenz
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393527
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Stein Somers <ss...@opnet.com>.
Eric B. wrote:
> Would that [retagging] concept/workflow cause problems in SVN?
I do it in an automated build process, and found it only a bit awkward you
have to delete the tag before adding it again. In pseudo code:
if (svn info the_tag)
# tag exists so delete it
svn del the_tag
svn copy the_revision the_tag
But I probably just lack the imagination and experience to do it in a single
transaction.
> require the client to download the entire code repository of a previous
> version?
No at all, you can access info, history and contents of each file
individually, both on the command line and in many GUI interfaces (at least
the two I used).
> revision for that one file and stick with it (ie: sticky tags).
I don't know the feature in CVS, but I could have used it in SVN. I don't
think there is a easy way. Even if it's an entire subfolder, SVN allows
"switching" it to a different branch, but I don't think you can pin it to a
revision of the current branch and still allowing updating the rest. Unless
you tag the pinned and switch the folder to be pinned to that tag, but that
involves a change in the repository
> Another problem I had read about a while back was with file renaming; I had
> understood it not to be fully functional.
If you rename a file or folder, all changes are taken into account very well.
The same for splitting a file in two (making a copy). Only if you start doing
more complicated stuff like merging such a "rename" to other branches where
other changes or renames have been done to the same file, you run into
conflicts. Before SVN 1.6, you sometimes didn't notice such conflicts.
Hopefully some day, SVN will help you resolve those conflicts. For instance,
you rename "foo" to "bar" but someone else renamed it to "baz". Right now
this is reported as a tree conflict, but if SVN were really smart if could
ask which of the two names you want in the end. As far as I know, from aging
experience, no system comes anywhere near what SVN already offers.
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393353
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Eric Roberts <ow...@threeravensconsulting.com>.
I don't remember where you get this at,so it will involve some huntingon
your part, but there is a program called something along the lines
of cvstosvn.exe that will convert CVS repositories to SVn repositories. We
used it an an old job of mine to make the switch.
Eric
On Thu, Sep 10, 2009 at 8:13 PM, Andrey Repin <an...@freemail.ru> wrote:
> Greetings, Les Mikesell!
>
> >>> Hmmm ... not sure I understand this concept entirely. I basically use
> a CVS
> >>> tag every time I do a build or a release to "mark" the version of all
> files
> >>> required for that particular build. 99% of the time, this tag is a one
> time
> >>> thing. However, it does happen every-so-often that a build fails b/c
> >>> someone forgot to check in a file. So instead of giving it a new build
> >>> number once the file is committed, I just retag with the same tag name
> and
> >>> perform the build. Would that concept/workflow cause problems in SVN?
> >>
> >> This is much less likely to happen with Subversion in general. As I
> said, each
> >> revision slicing the *whole repository* at a certain moment of time,
> which is
> >> supposed to be a complete and functional state. Yep, it's not certainly
> true,
> >> but since it is a complete state, you can always tell that "in this
> state a
> >> building process fails due to this issue, guys - get to work and resolve
> it".
>
> > A revision number recalls the state that the repository was in when a
> > certain transaction completed which doesn't necessarily imply anything
> > about the usability at the time.
>
> That's why i'm using the term "supposed". It's not a rule or anything, just
> a
> rude expectation, if you allow me to formulate it this way.
>
> > In CVS you would normally tag the
> > repository versions that match your workspace so you could subsequently
> > reproduce that workspace state, and you can do that by either adding a
> > new tag name or by 'floating' an existing tag to that position. To get
> > the same effect in subversion you might have to delete an existing tag,
> > then copy your workspace to a tag - which really isn't a very good
> > practice since you can easily include things that aren't committed
> > elsewhere.
>
> >> At the time you see a revision worth branching to the /release, you run
> last
> >> checks over it and if it is suitable, you "tag" this revision to
> appropriate
> >> place in repository. It does not need a floating tags to continue your
> work
> >> tomorrow, the revision umber already has this function for you. Even if
> there
> >> was commits after the desired revision, you can still refer to the
> desired
> >> revision and finish your work in one way or another.
>
> > But the point is that you need to know this revision number to use it
> > for anything. With the floating CVS tags you could embed a known name
> > (like RELEASE, RELEASE-1, RELEASE-2) and float the names to appropriate
> > revisions to be picked up by subsequent processing. With svn, you have
> > to pass revision numbers or tag names around or do something strange
> > like deleting tags (which aren't really deleted except for the HEAD
> > view) in the repository. That's not necessarily a bad thing, just
> > different.
>
> Right all this. It's just one of the caveats you expect from changing your
> tools. The new tool does it's work, just in a slightly different way.
> As always, there's advantages and disadvantages to this.
> In this example situation, I can give the need to adapt your building tools
> to
> the Subversion specific as a disadvantage - it require extra work, but as
> advantage, you'll get a tool in the end, that could work with any random
> revision in the repository without touching it's structure in any way (if
> adaptation was done in the way to allow specifying a certain revision
> rather
> than addressing some constant path in a repository), which could not be
> easily
> achieved with CVS.
>
>
> --
> WBR,
> Andrey Repin (anrdaemon@freemail.ru) 11.09.2009, <5:06>
>
> Sorry for my terrible english...
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393482
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393483
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Les Mikesell!
>>> Hmmm ... not sure I understand this concept entirely. I basically use a CVS
>>> tag every time I do a build or a release to "mark" the version of all files
>>> required for that particular build. 99% of the time, this tag is a one time
>>> thing. However, it does happen every-so-often that a build fails b/c
>>> someone forgot to check in a file. So instead of giving it a new build
>>> number once the file is committed, I just retag with the same tag name and
>>> perform the build. Would that concept/workflow cause problems in SVN?
>>
>> This is much less likely to happen with Subversion in general. As I said, each
>> revision slicing the *whole repository* at a certain moment of time, which is
>> supposed to be a complete and functional state. Yep, it's not certainly true,
>> but since it is a complete state, you can always tell that "in this state a
>> building process fails due to this issue, guys - get to work and resolve it".
> A revision number recalls the state that the repository was in when a
> certain transaction completed which doesn't necessarily imply anything
> about the usability at the time.
That's why i'm using the term "supposed". It's not a rule or anything, just a
rude expectation, if you allow me to formulate it this way.
> In CVS you would normally tag the
> repository versions that match your workspace so you could subsequently
> reproduce that workspace state, and you can do that by either adding a
> new tag name or by 'floating' an existing tag to that position. To get
> the same effect in subversion you might have to delete an existing tag,
> then copy your workspace to a tag - which really isn't a very good
> practice since you can easily include things that aren't committed
> elsewhere.
>> At the time you see a revision worth branching to the /release, you run last
>> checks over it and if it is suitable, you "tag" this revision to appropriate
>> place in repository. It does not need a floating tags to continue your work
>> tomorrow, the revision umber already has this function for you. Even if there
>> was commits after the desired revision, you can still refer to the desired
>> revision and finish your work in one way or another.
> But the point is that you need to know this revision number to use it
> for anything. With the floating CVS tags you could embed a known name
> (like RELEASE, RELEASE-1, RELEASE-2) and float the names to appropriate
> revisions to be picked up by subsequent processing. With svn, you have
> to pass revision numbers or tag names around or do something strange
> like deleting tags (which aren't really deleted except for the HEAD
> view) in the repository. That's not necessarily a bad thing, just
> different.
Right all this. It's just one of the caveats you expect from changing your
tools. The new tool does it's work, just in a slightly different way.
As always, there's advantages and disadvantages to this.
In this example situation, I can give the need to adapt your building tools to
the Subversion specific as a disadvantage - it require extra work, but as
advantage, you'll get a tool in the end, that could work with any random
revision in the repository without touching it's structure in any way (if
adaptation was done in the way to allow specifying a certain revision rather
than addressing some constant path in a repository), which could not be easily
achieved with CVS.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 11.09.2009, <5:06>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393482
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Les Mikesell <le...@gmail.com>.
Andrey Repin wrote:
>
>> Hmmm ... not sure I understand this concept entirely. I basically use a CVS
>> tag every time I do a build or a release to "mark" the version of all files
>> required for that particular build. 99% of the time, this tag is a one time
>> thing. However, it does happen every-so-often that a build fails b/c
>> someone forgot to check in a file. So instead of giving it a new build
>> number once the file is committed, I just retag with the same tag name and
>> perform the build. Would that concept/workflow cause problems in SVN?
>
> This is much less likely to happen with Subversion in general. As I said, each
> revision slicing the *whole repository* at a certain moment of time, which is
> supposed to be a complete and functional state. Yep, it's not certainly true,
> but since it is a complete state, you can always tell that "in this state a
> building process fails due to this issue, guys - get to work and resolve it".
A revision number recalls the state that the repository was in when a
certain transaction completed which doesn't necessarily imply anything
about the usability at the time. In CVS you would normally tag the
repository versions that match your workspace so you could subsequently
reproduce that workspace state, and you can do that by either adding a
new tag name or by 'floating' an existing tag to that position. To get
the same effect in subversion you might have to delete an existing tag,
then copy your workspace to a tag - which really isn't a very good
practice since you can easily include things that aren't committed
elsewhere.
> At the time you see a revision worth branching to the /release, you run last
> checks over it and if it is suitable, you "tag" this revision to appropriate
> place in repository. It does not need a floating tags to continue your work
> tomorrow, the revision umber already has this function for you. Even if there
> was commits after the desired revision, you can still refer to the desired
> revision and finish your work in one way or another.
But the point is that you need to know this revision number to use it
for anything. With the floating CVS tags you could embed a known name
(like RELEASE, RELEASE-1, RELEASE-2) and float the names to appropriate
revisions to be picked up by subsequent processing. With svn, you have
to pass revision numbers or tag names around or do something strange
like deleting tags (which aren't really deleted except for the HEAD
view) in the repository. That's not necessarily a bad thing, just
different.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393399
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Eric B.!
> Hmmm ... not sure I understand this concept entirely. I basically use a CVS
> tag every time I do a build or a release to "mark" the version of all files
> required for that particular build. 99% of the time, this tag is a one time
> thing. However, it does happen every-so-often that a build fails b/c
> someone forgot to check in a file. So instead of giving it a new build
> number once the file is committed, I just retag with the same tag name and
> perform the build. Would that concept/workflow cause problems in SVN?
This is much less likely to happen with Subversion in general. As I said, each
revision slicing the *whole repository* at a certain moment of time, which is
supposed to be a complete and functional state. Yep, it's not certainly true,
but since it is a complete state, you can always tell that "in this state a
building process fails due to this issue, guys - get to work and resolve it".
At the time you see a revision worth branching to the /release, you run last
checks over it and if it is suitable, you "tag" this revision to appropriate
place in repository. It does not need a floating tags to continue your work
tomorrow, the revision umber already has this function for you. Even if there
was commits after the desired revision, you can still refer to the desired
revision and finish your work in one way or another.
> Secondly, I'm a bit confused with the concept of version numbers in svn
> overall. I understand that a version relates to the state of the overall
> project - not any individual file as in CVS. So if I am working in a
> specific file, and want to see a previous version of that file, does that
> require the client to download the entire code repository of a previous
> version?
Absolutely, no.
Just ask server about changes made to the file and you can see in which
revisions it was touched in which way.
If you just want to compare HEAD version to previous state, you can use
revision ranges to retrieve previous version of the file.
> In CVS, since files are versioned independently, I can easily see
> the state of any one file throughout its history, and retreive a particular
> revision for that one file and stick with it (ie: sticky tags). Does that
> concept still hold true for svn?
Not directly, but it's still possible to track revisions in which file was
modified or in any way affected.
However, you can't put your changes in before the HEAD.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 10.09.2009, <21:22>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393377
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Move from CVSNT to SVN?
Posted by Bob Archer <bo...@amsi.com>.
> > This may not be difficult but if you floated tags in CVS instead of
> > making up
> > new ones for every change you may need to change your process with
> svn.
>
> Hmmm ... not sure I understand this concept entirely. I basically use
> a CVS
> tag every time I do a build or a release to "mark" the version of all
> files
> required for that particular build. 99% of the time, this tag is a one
> time
> thing. However, it does happen every-so-often that a build fails b/c
> someone forgot to check in a file. So instead of giving it a new build
> number once the file is committed, I just retag with the same tag name
> and
> perform the build. Would that concept/workflow cause problems in SVN?
No, it won't be a problem. Just delete the tag and re-create it. We do this also.
> Secondly, I'm a bit confused with the concept of version numbers in svn
> overall. I understand that a version relates to the state of the
> overall
> project - not any individual file as in CVS. So if I am working in a
> specific file, and want to see a previous version of that file, does
> that
> require the client to download the entire code repository of a previous
> version? In CVS, since files are versioned independently, I can easily
> see
> the state of any one file throughout its history, and retreive a
> particular
> revision for that one file and stick with it (ie: sticky tags). Does
> that
> concept still hold true for svn?
Yes, a WC can have "mixed revisions" so you can "update" a specific folder to a certain revisions. Generally you want everything to be at the HEAD (most recent) revision, but you can update a path or a single file to a previous rev number. Also, svn will keep you from committing changes to it since it will recognize that it is older than the HEAD revision. There are also tools to diff what is in your working copy with a previous revision of the file.
The main difference is that a file could be the same in several revisions. But, that is just semantics and doesn't really affect anything.
>
> Another problem I had read about a while back was with file renaming; I
> had
> understood it not to be fully functional. Is that the case, or was I
> misinterpreting information?
You can "rename" files but internally it is a delete and then an add. But, subversion is smart enough to keep ancestry in tact. The confusion comes when you rename say "filea" to "fileb" then create a new "fileb". That can make svn loose it's mind abit.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393351
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by "Eric B." <eb...@hotmail.com>.
"Les Mikesell" <le...@gmail.com> wrote in message
news:4AA8F483.7070801@gmail.com...
>>> You may need to adjust your workflow concepts a bit. In CVS, you would
>>> normally use tags to tie a set of revisions together so you can
>>> reproduce the state of a workspace - and in cvs tags are like labels
>>> that you can float around. In subversion, tags are like snapshot
>>> copies and normally are never revised so if your workflow depends on
>>> floating a tag name so you can embed it in scripts you may have to
>>> change a few things.
>>
>> I'd like to add that this concept of "floating tags" is what Subversion
>> has in
>> mind when you say "revision".
>> Each revision consist of a complete, functional state of the project....
>> ideally.
>
> Yes, except you don't get to apply a well-known name to it. So it is hard
> to
> embed the right revision number into an already written script... With
> CVS you
> are generally forced to use tags because each file will have different
> revision
> numbers and you need the tags as labels to identify the right revisions
> for a
> set of files. With svn you can use tags but it is hard to re-use the same
> name
> to identify a state that is ready for some processing step so you need to
> come
> up with some extra workflow steps to pass a tag name or revision number
> around.
> This may not be difficult but if you floated tags in CVS instead of
> making up
> new ones for every change you may need to change your process with svn.
Hmmm ... not sure I understand this concept entirely. I basically use a CVS
tag every time I do a build or a release to "mark" the version of all files
required for that particular build. 99% of the time, this tag is a one time
thing. However, it does happen every-so-often that a build fails b/c
someone forgot to check in a file. So instead of giving it a new build
number once the file is committed, I just retag with the same tag name and
perform the build. Would that concept/workflow cause problems in SVN?
Secondly, I'm a bit confused with the concept of version numbers in svn
overall. I understand that a version relates to the state of the overall
project - not any individual file as in CVS. So if I am working in a
specific file, and want to see a previous version of that file, does that
require the client to download the entire code repository of a previous
version? In CVS, since files are versioned independently, I can easily see
the state of any one file throughout its history, and retreive a particular
revision for that one file and stick with it (ie: sticky tags). Does that
concept still hold true for svn?
Another problem I had read about a while back was with file renaming; I had
understood it not to be fully functional. Is that the case, or was I
misinterpreting information?
Thanks for the info!
Eric
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393327
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Les Mikesell <le...@gmail.com>.
Andrey Repin wrote:
> Greetings, Les Mikesell!
>
>> You may need to adjust your workflow concepts a bit. In CVS, you would
>> normally use tags to tie a set of revisions together so you can
>> reproduce the state of a workspace - and in cvs tags are like labels
>> that you can float around. In subversion, tags are like snapshot
>> copies and normally are never revised so if your workflow depends on
>> floating a tag name so you can embed it in scripts you may have to
>> change a few things.
>
> I'd like to add that this concept of "floating tags" is what Subversion has in
> mind when you say "revision".
> Each revision consist of a complete, functional state of the project....
> ideally.
Yes, except you don't get to apply a well-known name to it. So it is hard to
embed the right revision number into an already written script... With CVS you
are generally forced to use tags because each file will have different revision
numbers and you need the tags as labels to identify the right revisions for a
set of files. With svn you can use tags but it is hard to re-use the same name
to identify a state that is ready for some processing step so you need to come
up with some extra workflow steps to pass a tag name or revision number around.
This may not be difficult but if you floated tags in CVS instead of making up
new ones for every change you may need to change your process with svn.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393225
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Les Mikesell!
> You may need to adjust your workflow concepts a bit. In CVS, you would
> normally use tags to tie a set of revisions together so you can
> reproduce the state of a workspace - and in cvs tags are like labels
> that you can float around. In subversion, tags are like snapshot
> copies and normally are never revised so if your workflow depends on
> floating a tag name so you can embed it in scripts you may have to
> change a few things.
I'd like to add that this concept of "floating tags" is what Subversion has in
mind when you say "revision".
Each revision consist of a complete, functional state of the project....
ideally.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 10.09.2009, <15:06>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393201
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Move from CVSNT to SVN?
Posted by Les Mikesell <le...@gmail.com>.
Eric B. wrote:
> I'm considering a switch from CVSNT to SVN and am looking for feedback from
> people who have made the switch in the past. Are you happy with your new
> choice? Does SVN allow you to be more productive than CVS? What prompted
> the move? What features are you able to use with SVN that you didn't have
> with CVS? From the flip side, are there reasons you regret making the
> change? Are there things in SVN that are more complicated or difficult to
> acheive than CVS? Or are some tasks with SVN more error-prone?
You may need to adjust your workflow concepts a bit. In CVS, you would
normally use tags to tie a set of revisions together so you can
reproduce the state of a workspace - and in cvs tags are like labels
that you can float around. In subversion, tags are like snapshot
copies and normally are never revised so if your workflow depends on
floating a tag name so you can embed it in scripts you may have to
change a few things.
> I have a large CVS repository from 10yrs of code that I would be moving
> over, so it isn't a decision that I'm going to be making lightly.
I'd do a practice run of the conversion and make sure you can still
build things the way you want.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393066
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].