>> Would you care to mention the difficulties with properties? All I can
>> think of is:
>> 1. It is not possible to commit changes to single property on a
>> file/directory.
>> 2. It is not simple to search properties based on their values. Or sort
>> the properties based on their values.
>
> These are the main issues with using properties as I see them:
>
> 1) The property needs to be available in the WC to be used. If the tag
> property is just on a specific folder, and you checked out some
> sub-folder, then now you don't have the property available to be used.
A 'tag' is supposed to tag a 'project' (the trunk, a branch or once the
working copy of some committer). If a developer is not working with that
project, but has checked out a subtree, then the developer cannot
reasonably assume the 'tag' to work optimally. We might make it fail, or
there might be a performance hit.
Users comming from other VCSs are used to working with projects, and so we
cover those Use Cases 100%. For Subversion oldtimers, well they are mostly
satisfied with the current scheme. So in any case this cannot be a
showstopper.
> This is why the feature works in Subclipse, because there are very
> specific folders that an Eclipse user will check out. Setting the
> property on every folder is unmanageable.
I agree.
I believe we should put properties on the trunk directory, all branch
directories and all tag directories, and the property should explicitly or
implicitly reference the same 'project'.
Whether a directory needs to be marked as the 'project' directory, I do
not know yet.
Subclipse could just check for a trunk, branch or tag, and if found it
would be able to find all branches and tags through the 'project'.
> The solution we have talked
> about is something called "inherited properties", but there are some messy
> issues to deal with to do that.
If the user checks out a branch, and runs "svn diff -r version-1.0" deep
inside the tree, then what's wrong with walking up the directory tree
until we find the 'project'? There may be a slight performance hit by
checking for a specific property on every directory, does anybody know how
much? 100ms at most? In any case, I cannot believe this would be
significant, as most users will be close to the 'project' when running
such commands.
> 2) You cannot set a property directly on a URL. This is technically
> feasible, it just has not been allowed or exposed. In this case, since
> you'd only want to append to the existing value, maybe it would be a
> capability that could be added?
>
> 3) Since properties are versioned, they require a commit. This might be
> the sort of thing that could be combined with #2 so that if we had a
> special svn tag command, it could under-the covers, to the copy and the
> update of the tag property in a single atomic operation.
I agree with your suggestion.
> 4) Once you have properties they are not easily searchable. For this
> particular feature, I am not sure how significant a problem that is.
This should not be a problem for tags.
> 5) As others have pointed out, a single property value cannot easily
> express a complex mixed-revision tag.
Agreed, but this is not a problem of 'properties' alone, but with the fact
that Subversion-like tags is a snapshot of (any) historic tree, even trees
not otherwise in the repository, and generally the simplest way to
represent such a snapshot is by storing the whole tree.
There are too many people thinking we should continue with the current
Subversion-like tags, and that's fine with me. That just means the
solution needs to be a little different than what I have suggested in my
earliest emails.
And so a 'tag' should still be a Subversion-like tag, and the 'tag' is a
directory containing a snapshot of some historic tree. We should still set
a property on the tag directory, notifying clients that this directory is
a tag and that it relates to a specific 'project'.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 8 16:22:37 2006