On 28-Feb-06, at 12:08 PM, Rainer Deyke wrote:
> Gale, David wrote:
>> Rainer Deyke wrote:
>>> Note: You can (and should, in the absence of built-in merge
>>> tracking)
>>> keep track of merge points using the current tagging mechanism.
>> Or in the absence of a good way to record the last merged revision,
>> which revision aliases would give.
>
> Once again I ask, what actual technical benefits would you gain by
> recording the revision instead of using a cheap copy? I can think
> of many benefits of using cheap copies instead of recording the
> revision:
>
> 1. You can have a mixed revision merge point if you decide to merge
> just part of the branch to the trunk.
This can also be seen as a problem (a mixed revision tag). At that
point you are NOT labeling any particular point of development along
the trunk branch. The cheap-copy tags have no way of enforcing the
label concept, they are a different concept that can sometimes be
used to accomplish the same goals as true labels.
> 2. You have a hierarchical naming for merge point to match the
> hierarchical naming of branches, thereby keeping the repository
> clean when there are thousands of private branches.
Subversion does not enforce any naming conventions or hierarchical
structure at all... tags are ad hoc hacks implemented only by relying
on the subversion users to not make mistakes. This can be enforced a
little by hook scripts. Such hook scripts are not provided in a way
that they run out of the box on Windows. They are awkward to deal
with.
> Given those benefits and the absence of any drawback, I would
> strongly recommend using cheap copies instead of revision aliases
> for merge points, even if both were available.
Drawbacks:
- Cheap copies establish a new branch rather than marking a
significant point on an existing branch
- You must dig information out of the log command and use --stop-on-
copy to get at the information that the cheap copy is hiding (what is
it a copy of, when was it made)
- Cheap copies are mutable without complex scripts to prevent it.
- Such scripts rely on other hacks like using specific naming
conventions in the repository.
- Cheap copies can be created from anything... nothing within
subversion enforces the concept of a label I can copy the trunkof
Project B into the tags directory of Project A and subversion doesn't
know that I have totally mangled the concept of a tag/label.
Solution end users must deal with it with more complex scripting,
there is no direct support within subversion to manage such a concept.
- Merging based on comparing cheap copy branches (tags) makes no
sanity check to see that I am comparing different points of
development along the same branch.
- Subversion has no (efficient) way to find out things like what
labels have been made on a branch of development via the cheap-copy
mechanism (i.e. where has this branch been copied too). You can only
come from the other direction (from where was this copy made), end
even that is awkward. "True" labels would solve the case of listing
the significant points along the history of a branch in a much easier
to deal with way because it would not rely on the configuration of
hook scripts and adhering to conventions.
One argument that comes up is that you need both a path and a
revision to refer to something in subversion so you need more than a
revision alias. But I propose that the revision alias IS stored in a
path (could be the root as well). In this sense a label would be be
better because unlike a tag it does NOT create a new path. It labels
the existing path, which fits exactly the operation I was attempting
to do. It does not twist my label into "just make a copy of what you
have at that point" because that is a different thing. Labels allow
me to make a copy later if I want, but they don't make a copy as part
of the labeling process. On a timeline you can label points in time
- that doesn't split the timeline and create a new branch like the
current cheap copies do. Referring to a cheap copy of a branch can
give you the same data as referring to a branch at a specific
revision BUT it has totally different metadata attached to it (it's
by definition a different branch) and some of the important metadata
is awkward to get (--stop-on-copy)
Nobody is suggesting not using cheap copies, we are suggesting a new
feature that is focused on solving specific common problems that are
MORE suited to the problem domain than a cheap copy. We are asking
for something that is specifically LESS powerful than cheap copies in
some ways.
It reminds me of the saying "If all you have is a hammer, everything
looks like a nail." Why is there such pressure to solve every
problem with cheap copies? Because subversion already has cheap
copies. NOT necessarily because cheap copies are the better solution.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 28 21:30:05 2006