[Note: One serious question contained in here, the remainder being
more like atmospheric notes. Other than that, I'd be glad to see
a ^relative shortcut for URLs. And sorry for the late response,
I was on a completely offline seminar.]
On Thu, 26 Nov 2009 12:21:22 +0000, Stefan Sperling wrote:
...
> > > That said, what is the big deal with specifying --reintegrate?
> >
> > It just as stupid as to require to specify a revision range...
>
> And as stupid as keeping backwards-compatibility to 1.4?
That isn't given anyway, as far as I can see (which admittedly
isn't that far). svn merge behaves differently in 1.5 vs. 1.4,
and it could just as well behaved differently in a more predictable
manner. But then that has all already happened and can't be fixed
retroactively.
...
> or not). But there are exciting new ideas being worked on which will
> improve things a lot (e.g. the new working copy format, and a better
> client<->server API to communicate tree changes).
You know, it's a bit hard to be excited about that after being
seriously pampered by git.
> I'd like you to stay around and monitor improvements we'll make in
> 1.7 and subsequent releases.
My current status is 'captive rider', and that is pretty much
predicated on --reintegrate.
> It's not easy to turn something that started out as a better CVS (a goal
> which has arguably been reached long ago)
That is pretty definitely the case (except for a very slight flunk with
eol-style).
> into a magic wand that does
> everything you ask it to do, by reading your mind and translating your
> personal brain-wave patterns into version control, and make it all
> backwards compatible, too.
Actually, the one thing I *do* expect nowadays is proper merge tracking;
Clearcase did that ten years ago, and git got there from zero almost
faster than svn got from the announcement to 1.5.
....
> > ...and needing to specify --reintegrate nowadays is the definition of
> > 'does not work properly'.
>
> Wow, that's harsh judgement. I would accept this if Subversion could
> not do reintegrate merges.
It can do that since 1.0, you just need a bit more manual bookkeeping.
> But what you want to do is possible to do,
> maybe just not as conveniently as you would like, you have to type a
> total of 13 characters more (or use a shell alias). That's not "does not
> work properly". That's "the tool needs your help a bit because it's not
> smart enough".
That's actually the same. :-) My problem is that I can't always see what
merge exactly needs the --reintegrate, and thus I keep from branching
because of fear of some merge going bad (in the worst case either with
or without the option, because I did something wrong previously and
did not notice back then).
[Serious question here:]
For example: If I notice that the trunk actually developped
in a direction that should be on a branch, and I do like
svn mv trunk branch/newfeature
svn cp trunk_at_12345 trunk
(with 12345 being the last 'good' revision), and assuming that there
are no merges from or to trunk since 12345, will the mergeinfo between
trunk and the other branches in existence still do the right thing?
That is something I can't see without going deep into what cp and
merge actually do with the mergeinfo, and what my knowledge about
ancestry tells me should simply be no concern.
The same goes for any kind of branching that extends beyond simple
trunk and feature branches that interact only with trunk. With svn,
I'm simply afraid of painting myself into a corner there.
> But it still does most of the hard work for you.
> (And I guess git users especially don't consider typing command line
> options hard to do *cough* *cough* ;)
The problem is the deciding, not the typing (except that I'm allergic
to type things the system should know already). Other than that git
didn't mindread, they came up with a lot of functionality I didn't
even dream of, like 'git add -p' or the stash. 'git clean'.
'git describe'. All of which are pretty orthogonal to the
distributed operation, and would suit svn very fine.
(Unfortunately git-svn doesn't play well with svn:externals.)
...
> And these others have other problems that svn doesn't have.
> Try locking a jpeg file for exclusive access in other systems so you
> don't have to merge it.
svn locks the jpeg in all branches it exists in?
> Try hiding a folder from a particular user.
Don't let that user do merges. :-)
> Try merging a refactored directory tree and get warnings that all your
> java packages are now messed up and contain classes that don't belong
> in there.
That's actually also svn. Hint: The path of the .javas change by the
directory rename, but nobody thinks of fixing the package declaration.
I'm not sure that your favorite IDE will actually tell svn that the
directories have been renamed, instead of just creating the new ones.
Which again is a good reason why svn needs a plugin in the first place.
> Many can't do it while also providing the other features svn
> provides. But maybe they can do bi-directional merges without any command
> line flags, or they can handle file-renames automatically with only few
> false positives,
Actually I just had the case where someone renamed a .c into .cpp
(and fixed accordingly). Only that he removed the .c three revisions
later. git had the chuzpa to take that as a rename and do a resulting
merge right! (Well, diff has one file vanished and a very similar appear:
Bingo.) You'd have to trick svn to do the same merge, once the svn cp
was missed and the .cpp added independently.
> or maybe they have better performance because all they do
> is disk i/o. There is no perfect tool, it depends on what you need.
Well, yes. Life will be easier when svn reaches my personal 'acceptable'.
Andreas
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425296
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-29 23:00:21 CET