Re: Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 17 July 2008, Craig L. Ching wrote:

> For instance, SVN has a history of having to invent concepts that just
> shouldn't need to be invented.  Their latest release includes something
> they call "merge tracking", but it falls on the floor in the face of
> what they call "reflective merging." [1]  I don't find "merge tracking"
> and "reflective merges" concepts that I should *have* to understand when
> it comes to working with a VCS, the VCS should just *do* those things.
> Those concepts just don't exist in Git.  Frankly, I don't find
> Subversion to be easier to use than Git at all and this is coming from a
> very long-time CVS user.  I do find, however, that Git has a very large
> vocabulary and that does take some time to learn, but I'd argue that
> this is due to it's inherent flexibility than it is due to any inherent
> flaws.
> 
> [1] -- http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

WTF!?!

Without merge tracking (which at minimum means that commits which are
result of [true] merging contain information about which commits were
merged) you can't really display and reconstruct history.  Without new
svn:mergeinfo one had to rely on third party extensions (SVK or svnmerge)
or on information contained in commit message to get this info.  It is
very good that at last Subversion 1.5 finally does include merge
information.

But, if I understand correctly, and if information in mentioned blog
is correct, then Subversion _fails_ to use this information fully.
Instead of finding merge bases (see http://revctrl.org ... errr, it
is now full of spam, and there is no easy way to revert to some older
version, so you would have to browse history), and doing 3-way merge[1],
it requires of user to explicitly request automatical merge:

  $ svn merge --reintegrate url://feature-branch .

and from the blog it looks like Subversion just generates patch and
applies it.  Or do I understand it incorrectly?

[1] CVS did it, even Bram Cohen of Codeville agrees now[2] that 3-way
    merge is a correct way to go
[2] http://bramcohen.livejournal.com/52148.html 
    "3. Use 3-way merge"
-- 
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux