[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
We've been using SVN all of this year, and we're trying to get off it.
Branching is extremely easy, but I've never used a system in which
merging was harder - even in CVS it was easier to visualise and track
merges.
The basic issue is that all branches (and tags) are completely
independent, they have no relation to the part of the repository they
came from. This makes it impossible to answer the question "Where did
this branch come from?" or "What merges have been done to/from this
branch?" or even "From what version was this other branch created?",
without keeping extra information somehow - SVN properties can track
some things, but another team uses an Excel spreadsheet to manage its
branches.
The biggest issue with the above is that if anything goes wrong - eg, a
merge is misapplied - it is next to impossible to determine what went
wrong, or what needs to be done to fix it.
Our project is heavily concurrent though (average 2-3 active branches at
a particular time), so we run into these issues on a regular basis. If
development is largely serial, or branches have very well defined
relationships, this would become less of an issue.
Also, renames or moves in SVN constitute a deletion and an addition.
The only special feature is that the addition contains the same history
that the old file used to have. This is another problem for merges when
refactoring...
* File A.java exists in branch 1 and branch 2
* File A.java is modified in both branches
* File A.java is renamed to B.java in branch 1
* branch 1 is merged into branch 2...
Because A.java was "deleted" in branch 1, the merge will delete A.java
in branch 2, and take B.java as it exists in branch 1 and add it in to
branch 2. Because there is no remaining logical relationship between
A.java and B.java (as far as SVN is concerned), there was never any
opportunity to merge the changes in A.java in branch 2 with the new
B.java.
This is not to say that SVN won't be better than CVS for your purposes,
but these are the major issues we've run in to using SVN in our project.
Evaluate based on your requirements :-)
Regards, and luck,
--
Troy Laurin
Lurker
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Chris Recoskie
Sent: Thursday, December 14, 2006 7:34 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Subversion
I have always rather hated how CVS doesn't track renames (which is even
more horrible for Java where any rename of a class means renaming the
file), so my gut reaction is to say go for it.
I'll take a look in a bit more detail and make sure I'm not putting my
foot
in my mouth as per usual :-P
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
From: Doug Schaefer <DSchaefer@xxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: 13/12/2006 09:01 PM
Subject [cdt-dev] Subversion
:
Any thoughts about moving to subversion now that it?s available on the
eclipse.org servers?
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC Member
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
--------------------------------------------------------
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------
