lkml.org 
[lkml]   [2003]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BitBucket: GPL-ed KitBeeper clone
Linus Torvalds wrote:

> Now, it's true that in 90% of all cases (probably closer to 99%) you
> will never see the really nasty cases Larry was talking about. People
> just don't rename files that much, and more importantly: then whey do,
> they very very seldom have anybody else doing the same.

The Meta-CVS software handles conflicting renames quite nicely.
Corner cases such as these are handled smoothly:

- merging parallel moves of the same object to different names
- merging parellel moves of multiple objects to the same name
- name rotation situations: a renamed to b, b renamed to c,
c renamed to d, d renamed back to a, all committed as one atomic
change. You can update to before that change, and a b c d jump
to their original names in your sandbox; then update past the change
and they jump to their new names.
- merging deletion and modification of a file
- merging parallel additions of an object to the same name.

> On eof the things I always hated about CVS is how it makes it
> IMPOSSIBLE to "work together" on something between two different random
> people. Take one person who's been working on something for a while,
> but is chansing that one final bug, and asks another person for help.
> It just DOES NOT WORK in the CVS mentality (or _any_ centralized
> setup).

Meta-CVS has sane snapshot-importing feature: ``mcvs grab''. If
someone has some hacked version of a program that I released, he can
give me a snapshot, and tell me what release it is based from. I can
shoot a branch from that release baseline, and grab his snapshot to
that branch. It doesn't matter if he added, removed or moved files,
changed around symbolic links, or fiddled with execute permissions; all
is analyzed and represented. The software prepares the import by
converting the snapshot into a sandbox containing local changes that I
can review, then commit.

Just as I can have this branch for tracking his changes in my
repository, he can have a branch for tracking my changes in his.

These are not changesets, in the sense that I don't have a detailed
change history, only a single delta for everything. I have to write my
own commit comment for the snapshot. On the other hand, the input is a
simple snapshot, not a data structure produced by some specific version
control system that the other guy would have to use. I don't care if
he uses tarballs for his version control.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.024 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site