On Feb 22, 2008, at 11:35 AM, Santiago Gala wrote:
I had a number of responses to your comments in previous emails about
the distributed tools forcing isolated behavior, which you can
imagine I
disagree with, but I think it makes no sense to keep on with this kind
of discussion. I would just repeat a mantra about forks that I
heard (to
Sam?): the easiest you make forking, the most difficult is for it to
happen. The same, I think, applies to distribution here: the
easiest to
move patches around, the more they will "come" to the central point.
Umm, no, patches are text files. I think you mean the easier it is to
identify and apply patches, the more likely they won't be lost or left
behind.
The fact that people finds easier to do a clean checkouts to work on
different features, commit and delete, does not ask necessarily for
different work flows. For instance, I used to have two different svn
checkouts for this kind of split between small fixes and a longer term
"feature". Keeping the changes synced to both was mostly tedious.
Most patches I keep from gajim, which is a project I track "from the
outside", have been sent upstream and not accepted, for one reason or
the other. I got a lot accepted, but sometimes people does not have
the
same perception that I have, or just the same configuration. I *run*
the tools (a python jabber client) hours a day with those patches, so
I'm confident that they work. What should I do? trust them and throw
the patches away to get a less functional version? What I'm doing now
is keeping quilt and merging the patches every time I update svn from
them. I'm migrating to use git for that task after I tested git-svn
import
with the repository.
That is isolated development. If you participate within the project,
instead of outside it, then the presence of everyone's private tree
makes it very hard for anyone to know what has been accepted, let alone
test with the same configuration, plan for the same features, and
generally help each other out with the small stuff. What happens next
is that the trees become their own distributions, just like Debian and
Ubuntu and Redhat are not actually based on Linus' tree.
Likewise, if you intend to analyze the parts of gSCM systems that
don't
scale in the hope of finding fixes/workarounds, then by all means
do so.
As an example of the kind of experiments I think we can do here:
today I
did a (couple of) git-svn "clone" of incubator/shindig. It is much
smaller than a clean svn checkout, *while having full history*. It is
way faster to process because it is smaller. It is faster to process
because the depth of the history is much smaller than the whole ASF
tree, etc:
$ du -sh shindig git-shindig*
6,7M shindig
2,9M git-shindig <- read only, http
2,9M git-shindig2 <- can commit to svn, https
I can navigate and search the whole history, fast, etc.
Obviously git-svn is not a mature tool, git-svn has problems (or I am
stupid enough to blow it and make it fail silently), and even more
problems appear because there are impedance mismatches between the
stores of both tools. Also, fame is git is not exactly well supported
under windows. Not that I care for myself, I have not used windows
in a
number of years, but this is a problem for everything except
experimental usage.
Just don't assume that the folks who built Subversion (or people like
me,
who just did a lot of research on gSEE back in the 90s) are somehow
unaware of the advantages/disadvantages of dSCM.
Cool, I would ask you in exchange to don't assume that tools that are
used to manage several of the most dynamic projects in the world (the
linux kernel is one such) with a lot of success, and tools used by
companies such as Redhat or Ubuntu for a number of years are used
out of
masochism.
Dude, I already have Hg installed, watched Linus' rant the week
it was posted, and was well aware of bitkeeper, TeamWare, DARCS, and
several other long-abandoned dSCM tools years ago (I tried to install
git, but at the time it didn't work on anything but Linux). Most of
the dSCM legacy came directly or indirectly out of Solaris engineering's
tool groups and ex-Sun employees, which is one of the reasons they are
so friggin incapable of collaborating on even the simplest of tasks.
When you get to the part where you look at the storage formats and see
the trade-offs that have been deliberately chosen to benefit isolated
development at the cost of consensus development, then you will
understand where I am coming from. If you can fix that trade-off
without failing both models, then you'll have bettered both Linus
and the Subversion team. I'm not saying its impossible -- I am just
saying it is naive to think that the trade-offs weren't chosen
for a good reason.
Good luck,
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
