On Dec 19, 2005, at 20:45, Phil Endecott wrote:
> Granse, Erik (STP) wrote:
>
>> - Revision properties are a possibility, but we'd want to
>> associate the property to a specific file. Conversely, file
>> properties don't allow us to also associate the property to the
>> file at a specific revision.
>
> On the contrary, file properties are associated with particular
> revisions. You can set a "status" property to "approved" and
> commit it, and it's that particular revision that is affected.
> Subsequently you can change the status property to "released" and
> commit that. The log will show you which properties changed in
> which revisions.
Phil, I'm pretty sure Erik had it right in the first place. There are
two kinds of properties in Subversion:
* Versioned properties are attached to specific files and
directories, and to apply or remove them, you increase the repository
revision number.
* Revision (non-versioned) properties relate to a specific revision,
but are not bound to specific files or directories.
On Dec 19, 2005, at 18:18, Granse, Erik (STP) wrote:
> We have a need to identify particular revisions of particular files as
> 'baselined' (e.g., completed peer review, etc.). We need to be able to
> identify all files that have been baselined (and ideally, all files
> which have not been). A file may be re-baselined if changed. We've
> thought through a few different strategies and haven't found one that
> works well.
Erik, it sounds like you should consider having a trunk, where
development occurs, and a "reviewed" or "baselined" branch, to which
approved changes are merged.
When we deal with changes in our project's source code, we don't talk
about changes in files; we talk about changesets or revisions.
Implementing feature X may involve adding a block to an HTML
template, adding new images, adding methods to database abstraction
classes, calling them from the business logic files, and more. All
this together is a single changeset or revision. If we were to have a
trunk and a baselined branch, someone intending to move the feature
to the baselined branch would need to review all these changes as a
whole, not individually, and would also not need or want to concern
themselves too much with other parts of the affected files which may
relate to other features long since finished. Of course, if you're
not managing code but some other kind of files, this
interrelationship between files may not exist for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 19 23:24:49 2005