On 20.01.2012 12:20, Mark Mielke wrote:
> I know that Subversion has these limitations compared to ClearCase:
>
> 1) Merge tracking is done at a commit level rather than at a per file
> or directory level. This means more complex analysis as the per commit
> information is "lossy" compared to what ClearCase is able to achieve.
> However, I think the information is still mostly available - it just
> requires some effort to extract.
I agree with all of your points, except possibly about the lossy nature
of mergeinfo. A revision is just a set of files (and directories), an
that set + mergeinfo is isomorphic to ClearCase's concept of merge
arrows (note that mergeinfo contains paths).
My original assumption that something must be wrong with either
Subversion's model or its implementation also comes from my experience
with ClearCase, by the way. And from a bit of reading on configuration
management theory; just as you said, the higher-level concepts
(promote/demote, or your even more restricted examples, deliver/rebase)
are just special cases of a lower-level, direction-agnostic merge primitive.
> 2) Branch off points are mysteriously hidden. Captured within the
> underlying repository but not exposed to the client? I think I saw
> some discussion about making this information available to the client
> but I didn't follow the conclusion of this?
Branch-off points are one issue, but a more fundamental one IMO is that
the client knows nothing about object identity; IOW, when given two
path/revision pairs, the client must jump through a lot of hoops to
figure out if they refer to the same entity at different times and/or on
different branches.
> Putting all of the above together - I don't understand why
> --reintegrate is required. Maybe I'm just ignorant. :-)
Apparently just about as ignorant of the matter as I am ...
-- Brane
Received on 2012-01-20 14:01:28 CET