VCS comparison table

[Jakub Narebski]

Aaron Bentley wrote:
> Jakub Narebski wrote:
>> Aaron Bentley wrote:
> 
>>> What is the bad side of using merge in this situation?
>>
>> We want linear history, not polluted by merges. For example you cannot
>> send merge commit via email.
> 
> Oh.  Bazaar supports sending merge commits by email.
> 
>> Another problem is that you want to
>> send _series_ of patches, string of commits (revisions), creating feature
>> part by part, with clean history; with merge you get _final result_
>> which will apply cleanly, with rebase you would get that series
>> of patches will apply cleanly.
> 
> Yes, that's something that I'd heard about the kernel development
> methodology-- that a series of small patches is preferred to one patch
> that makes the whole change.
> 
> That's not the way we operate.  We like to review all the changes at
> once.  But because bundles are applied with a 'merge' command, not a
> 'patch' command, an old bundle will tend to apply more cleanly than an
> old patch would.

Perhaps it would be nice to have "bundles" in git too. As of now
we can save arbitrary part of history in a pack, but it is binary
not textual representation.

Some of git workflow stems from old, pre-SCM Linux kernel workflow
of sending _patches_ via email.


By the way, are bzr "bundles" compatibile with ordinary patch?
git-format-patch patches are. They have additional metainfo,
but they are patches in heart.
  
>>> and more.  Because Python supports monkey-patching, a plugin can change
>>> absolutely anything.
>>
>> Which is _not_ a good idea. Git is created in such way, that the repository
>> is abstracted away (introduction of pack format, and improving pack format
>> can and was done "behind the scenes", not changing any porcelanish (user)
>> commands), but we don't want any chage that would change this abstraction.
> 
> I'm not sure what you think Bazaar does.  In Bazaar, a repository format
> plugin  implements the same API that a native repository format does.
> 
> This is how bzr supports Subversion, Mercurial and Git repositories.

But if I remember correctly Subversion does not remember merge points
(merge commits), so how can you provide full Bazaar-NG compatibility
with Subversion repository as backend? Some repository formats lack
some features. Besides, as I said repository database and stuff is
quite well abstracted away.

In git we have import tools (most of them capable of incremental import),
a few exchange tools like git-cvsexportcommit, git-cvsserver, and
Tailor-like git-svn.
 
>> Changing repository format is not a good idea for "dumb" protocols;
> 
> I can't parse this.  Repository formats and protocols are different
> things, right?

"Dumb" protocols in git are protocols for which server provides access
to contents git repository plus some additional info (usually generated
using hooks). The client (be it git-fetch or git-push) discovers which
files to download or what to upload, but it only can download repository
"as is". So if server repository was created with repository format plugin,
and client doesn't have said plugin, you are out of luck.
 
>> native protocol is quite extensible
> 
> I was meaning dumb protocol extension.  I can't say how extensible the
> bzr native protocol is.

Native git protocol (git:// and git+ssh://) does feature discovery, then
negotiates what contents has to be send, and finally tries to send minimal
number of objects.

>> Adding
>> cURL based FTP read-only support to existing HTTP support was a matter
>> of few lines, if I remember correctly.
> 
> We support read and write over native, ftp and WebDAV (a plugin).  We
> also have readonly http support.

Git has read-only access over git:// protocol (served by git-daemon on
port 9418), read-write access over git+ssh:// protocol (you can limit
exposition using git-shell), read-only access via HTTP, HTTPS, FTP "dumb"
protocols, read-write access via WebDAV "dumb" protocol.

Git is open-source, we don't need plugins ;-)
-- 
Jakub Narebski
ShadeHawk on #git
Poland