On Dec 1, 2007 7:41 AM, Branko Èibej <brane@xbc.nu> wrote:
> Ben Collins-Sussman wrote:
> > On Nov 30, 2007 6:15 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> >
> >>> Yes, this is what the plan has been for quite a while now.
> >>>
> >> I'm glad to hear you say this :-). But, others seem to think
> >> differently, so it's important we hear from them too...
> >>
> >
> > I'm not sure what to say, guys. So much drama in such a small period
> > of time. Eesh.
> >
> > I know it's ridiculous (and rude) for a bunch of people who haven't
> > been paying attention to merge-tracking details show up at the last
> > minute and challenge a bunch of decisions that were made months ago...
> >
>
> ... but I'm going to be even ruder and more ridiculous anyway. Guys ...
> deferring basic functionality that everyone else (except CVS and
> SourceSafe) takes for granted -- after almost two years spent working
> heavily on merge tracking -- is a bit of a bore. Even more so because
> there's already an efficient way of doing merges right with a Subversion
> repository: it's called git-svn and works like a charm. Oh, and of
> course there's svk.
>
I've been looking for somewhere to mention this! I've recently been
playing around with both svk and git. In fact I've been using git-svn
to track my recent CLI relative-url work. Looking more into this I
have discovered some things.
First off, git-svn works great for tracking your personal merges, but
it doesn't have the ability to publish them to other Subversion users
(unless they clone your git repo, and I'm not even sure that is
supported). Also, I very quickly ran into a common issue that git's
merge had a terrible time figuring out. I tested it on my subversion
trunk WC (using update for the "merge", since the git-svn rebase was
the operation I was doing in git) and the conflict was infinitely more
understandable. I think it was maybe because Subversion's merge
algorithm looks at ancestry ?? Maybe?? I'm not sure. (FYI I added a
new function at the end of a file, then rebased that change on someone
else's newly added function. Git tried very hard to interleave the
changes which made the conflict markers basically unreadable.
Subversion correctly treated them as diff "chunks" and conflicted the
whole chunks). And the diffs of the interesting files were much
easier to obtain.
Not only that, but git just completely ignores tracking
cherry-picking. By simply defining merges and cherry-picking as two
completely separate commands, git advocates (*cough* Linus) can call
other VCS like Subversion "stupid" and "idiotic" because they "forget"
about merges. I'm pretty sure if you cherry picked several commits
from a branch, then decided to just merge the whole thing that git
would have it's own problems. Maybe I have a very Subversion-ized
mindset on the merge/cherry-pick concept but I really think that
ignoring cherry-picks only solves half the problem. Though admittedly
an important half for decentralized development.
But before going the git-svn route I tried to use svk for my local
tracking, since it didn't feel so much like treason :). However, my
first pull resulted in merge conflicts in three files that I had never
touched, so I just stopped there. Of course, I didn't like the single
repository containing everything concept anyway. Not to mention the
my revision/your revision confusion (git definitely got it right there
for a DVCS) or the fact that the wc's had no admin information in tree
to distinguish it from "just some directory".
> Let's face it. 4 years after 1.0, and a year after our svn-2.0-focused
> summit, Subversion is treading water. In the last two years, have we
> added *any* feature that's more useful than the code bloat it produced?
> We've not even solved the relatively simple problem of working correctly
> on case-insensitive filesystems -- which just happens to include about
> 99% of all computers in the world, according to latest estimates. Many
> version control projects that didn't even exist when svn-1.0 came out
> have caught up and surpassed Subversion in terms of version control
> functionality, performance and (!) reliability, while we've wasted time
> with non-profit corporations and trademark protection.
>
I haven't been following the case-insensitive filesytem issues myself,
I steer clear of those inferior filesystems. :) However, I have
noticed it coming up pretty often. I'm not sure that git really runs
that great at all on Windows the last I checked, and it seems to me
that Subversion does a pretty decent job being cross-platform. But
like I said I've not used those "other" systems much.
> I'm not going to try to analyze the reasons here, except to note that
> losing sight of the ball does not help, nor does resting on laurels.
> Quite frankly, if I were setting up a configuration management
> infrastructure from scratch today, I'd probably not select Subversion as
> the version control system; that's how far things have gone off course.
>
> So ... we've made many wrong decisions, and I admit to making or
> supporting quite a few of them. But I don't see any reason for
> perpetuating them. So I suggest you (we?) all take a step back and
> *seriously* start moving in the right direction; otherwise in the next
> few years, Subversion and CVS will be jostling for the best position in
> the dinosaur exhibit of the trash-heap of history.
>
That's a great idea. So what do you propose is the "right" direction?
I'm sure the devs are open to suggestions. There is much work going
on trying to solve the merge-tracking problem (for both wholesale
merges AND cherrypicking) and I'm pretty sure I've seen various emails
about the case-insensitivity issue flying around (and it doesn't seem
like a particularly "simple" problem).
> -- Brane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
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/)
Received on Sat Dec 8 20:05:24 2007