On Sat, Nov 15, 2008 at 9:09 PM, Juliano F. Ravasi <ml(a)juliano.info> wrote:
Branching is a more general term. An svn checkout, for
example, is a
branch. Not the kind of named branch you create in the repository, but a
small, one-level branch, nevertheless.
Well, okay. You're probably using research terminology instead of
programming terminology. By "branch" most of us mean what SVN, git,
etc. call a "branch".
Most branches created in Subversion are release
branches and tags
(create-only, locked branches), that either don't require merge
tracking, or share only single commits between them.
Okay, true. I don't think that's what we're talking about.
Not really. To explain, I'd have to dig too much
into the inner workings
of both Git and Svn. But in short, they both boil down to very similar
procedures. The difference is in how this information about the merge is
stored and interpreted. Also, since Svn was born as centralized, the
information registered and immediately available on svn log doesn't
match what a Git user would expect. It is possible (but still
cumbersome) to check the diffs in svn:mergeinfo properties, and extract
the same information very similar to what Git stores.
Okay, well, the implementation isn't of much concern to me. I'm a
user, not a researcher. I would like it to work nicely, that's all.
I'm suggesting SVK just because AFAIK MediaWiki is
not yet planning to
move to distributed version control. When that day comes, then surely
there are much better tools than SVK.
Well, okay. The original request, though, was about branch merging
specifically. Does SVK help with that at all? If not, it's not
useful for the present purpose.
What is it, specifically, that people don't like about SVN branches,
anyway? In my case, I don't like branches because I tend to create
them, switch back to the main repo to do something else, totally
forget about my branch, and then eventually delete it when it's
obvious I'm too lazy to ever finish my work on it. :) Or in other
words, I've never really *used* them. And I've never used git
branches much either, only rebasing (which isn't good for publication,
although it's great for maintaining private patch sets). So I can't
give much of an opinion here.
On the other hand, the way we often handle this kind of stuff is to
just let the two implementations sit in trunk together, divided by a
configuration setting, so devs can switch to the new one and the live
site still uses the old one, but everything is in trunk. Then when
the new one is done, we remove the old one entirely. (Or not. Can
you hear me, Parser_OldPP? Are you still alive?!) This seems like a
pretty decent approach to the search issue.
Directory version isn't just about empty
directories. Directory
versioning also plays a big role for move/rename history tracking, merge
tracking and version control metadata (Svn properties).
Simple example: you rename a directory with a thousand versioned files
inside. You don't make any changes to the files, just the directory name.
In Svn, it is recorded as a single directory move operation, all files
register *no* change, since they actually weren't touched.
In Git, it is recorded as a thousand files removed, plus a thousand
files added, which is a *wrong* description of what happened. Also,
since Git doesn't record rename history upon commit (that happens only
once), this information has to be figured out later (that may happen
many times) using an exponential-complexity algorithm. It doesn't make
any sense when you think about it.
I don't really care, as long as it works, and so far it has for me --
without my having to remember to bother with "git cp" or similar
special commands. As long as it's fast enough for what I'm doing,
implementational purity doesn't matter as much as convenience, and git
has a slight win in convenience here, at least at commit time.
I use it, with MediaWiki's repository. Using it, I
can sync between MW's
repo, my local mirror, and my own public MW repo using it, something
that would be extremely difficult with git-svn.
Well, Andrew has said he's using git-svn to sync his working copy
between multiple computers. I don't know if he makes any of them
public.
Rewriting history is something that SVK doesn't
support by design. To
rewrite history means to lose information, and that is considered wrong
(even if you think that you won't need the overwritten history anymore).
That doesn't mean you can't *recreate* a new history as you like. You
rebranch from the point you want to recreate, do whatever changes you
want until the head of the former branch, then delete the former branch.
You have the same effect, but information is never lost forever. If you
find that you screwed up something trying to recreate the history, the
old history is still there to aid you.
Well, in git you can recover the history as well, if you try hard
enough and haven't run git-prune. :) Keeping the appropriate
original authorship dates when rewriting history is important when I'm
maintaining live patches to third-party software -- admittedly a
specialized case, but one of my main uses of git -- because I want to
know when the patch originally went live. I gather your method
wouldn't do that.
SVK doesn't even create *any* bookkeeping
directory, unless you order it
to do so. SVK checkouts are *completely* clean by default. So this is
even less of an issue for SVK.
Although, it's a PITA for Subversion. :(