Chris,
Although I'm fluent in SVN, I know nothing about GIT, and it sounds like
any real technical debate on the 2 tools won't work unless someone can
lay them both out with a glossary.
So it sounds like the intent of SVN externals is to allow binding
together pieces that exist in different SVN repositories.
Different projects in the same repository is just as likely. One common
use for me is to keep the common toolkit directories in separate
projects, and external them in to all the other projects that need them.
You can think
of a "superproject" as yet another Git repository that contains other
Git repositories
This is exactly what I often do with SVN - I have some projects with
nothing in them but a collection of externals definitions.
As for terms ... with git, you mentioned "clone", "wrapper", and "pull".
With SVN, I'd be talking about "external", checkout, commit, status, and
update.
That's why I think we have a bit of a language barrier comparing the
two. And I KNOW there is a concepts barrier, since GIT is definitely not
just the next subversion.
Some groups are bridging the 2 together ... SVN for the master
repositories, and GIT for the working ones. Apparently, there are some
tools that do local conversions from git to svn and back.
At some point, I'd like to see a case study of someone who switched from
SVN to GIT and how it was better ... or worse.
I could have written that case study from CVS to SVN based on personal
experience. I'm sure there are some other sites with good writeups of
svn-vs-git. Not just features, but actual benefits.
Sp
Sean Phelan
http://www.sqcn.com - Web Development & Management by Sequoia Consulting
http://www.VIRTUssist.com - Secretarial And Virtual Assistant Services
(321)698-7987
Chris Knadle wrote:
On Tuesday 12 January 2010, Sean Phelan wrote:
Is this comparable to SVN's externals?
I think they're similar but different, because they're each done for
different reasons.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
"once one person has made the effort to define those nested working
copy checkouts, no one else has to bother—Subversion will, upon
checkout of the original working copy, also checkout the external
working copies."
So it sounds like the intent of SVN externals is to allow binding
together pieces that exist in different SVN repositories.
However the intent of doing a Git "superproject" is to allow you to do
a clone of only one (or more) of the submodule repositories, due to a
lack of an easy way to check out only part of a tree. You can think
of a "superproject" as yet another Git repository that contains other
Git repositories -- i.e. another layer of "git wrapper". More
importantly, doing a "clone" of the Git superproject does not
auotmatically give you a clone of every submodule; that's a separate
operation. It likewise changes how a 'git pull' operates -- "you have
to run git submodule update after git pull if you want to update
submodules, too." (see one line up from the heading at:)
http://www.kernel.org/pub/software/scm/git/docs/user-
manual.html#_pitfalls_with_submodules
-- Chris
_______________________________________________
Mid-Hudson Valley Linux Users Group http://mhvlug.org
http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug
Upcoming Meetings (6pm - 8pm) MHVLS Auditorium
Feb 3 - Arduino
Mar 3 - Sahana and 7 Years of MHVLUG Celebration
Apr 7 - Nagios
