On Nov 28, 2006, at 3:42 PM, L. Wayne Johnson wrote:
>>>
>
> Now that's not silly. I don't believe that I have heard anyone say
> the rev
> props are inherently bad. Currently there isn't a way to set them
> at commit
> time. Since they aren't versioned allowing them to change means
> information
> can be lost.
As I've noted repeatedly, this speaks to a hole in the Subversion
revprop model. The logic seems to go something like this:
Changes to an existing revision are bad.
Revprops change an existing revision.
Therefore, revprops are bad.
However, this is faulty logic; revprops only change an existing
revision when applied retroactively. There is thus a fundamental
difference between a revprop applied at commit time (harmless) and a
revprop applied retroactively (potentially dangerous); this
distinction is not made in the existing command set nor in the hook
scripts. This means that I cannot realize my defect tracking scenario
without also exposing existing revisions to potential mutation. No
amount of script wrapping or hooking can overcome this.
> The philosophy of the subversion team is that nothing should
> ever get lost. There is nothing stopping you from enabling them
> except for a
> semi-trivial hook script. There could be other dangers of which I
> am not
> aware. The point is that there are 2 choices:
>
> 1. Subversion makes no assumptions about repository layout or how
> it will be
> used. This allows subversion to support many different methodologies.
> HOWEVER, this means that the end user has to do most of the work
> required to
> ensure that the processes that accompany the methodology are
> carried out
> correctly.
>
> 2. Subversion enforces specific methodologies. This is less work
> for the end
> user as certain conventions and processes are already enforced by the
> software. This is great as long as your methodology matches what the
> developers decide on.
Yes, I agree with your assessment, and I also totally agree with the
Subversion philosophy. However, whenever you create a generic tool
that attempts to be policy/workflow neutral, you still have a certain
commitment to provide the underlying features to allow typical-use
workflows to be layered onto that tool. My assertion is that the lack
of a safe revision-level metadata system is an example of such a
missing feature.
>
> For better or worse the subversion project appears to have adopted the
> first. I think it works pretty well. There are certainly things
> missing.
> Since we aren't paying any of the developers they get to decide
> what's most
> important. Currently they are working on true renames and merge
> tracking
> (among other things.) Both of these seem more important to me than
> labels.
>
Quite possibly, but this is a prioritization argument rather than a
pro/con argument regarding the merits of labels or revision metadata.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 05:06:11 2006