Hello Kevin,
> A custom properties column would not work here since we are looking
> for repository forensics behavior rather than working copy details
Ok, that was not clear to me before.
> Does our desire in having the repository browser "show log" display
> all the information it has per revision make more sense now?
Yes, it does. I'm not sure, but it might be a time-consuming task to
find out properties for all revisions. Anyway, I have put it on the RFE
list.
--
Best regards,
Marc Strapetz
_____________
syntevo.com
dibbledong wrote:
>> we could introduce some "custom properties" column,
>
> A custom properties column would not work here since we are looking
> for repository forensics behavior rather than working copy details
> behavior. What would work is, when browsing the repository, the show
>; log window also shows all properties that are tied to a particular
> repository revision.
>
>>; The working copy does not contain such information ...
> Not concerned with working copy but rather the repository. If we want
>; to pull down a previous revision based off of information contained in
> a revision's properties we have no way to find that using smartsvn.
>
>>; Why do you need to know, when properties have been added/modified?
> Don't need to know when they have been added/modified, however we do
> need to know if and what they are per-revision if they exist.
>
>>; I think important is that your current revision of a file
>>; has certain properties (or not).
> Only true if you are only concerned with only your working copy. The
> repository and all the historical information stored in it is what is
> most important. The fastest why to find a newly reported bug is to
> compare older code releases to newer ones. So, when trying to resolve
> a bug may have to dig around in the repository to find all the
> information you can that pertains to a massive number of commits. Now
> I ask, is doing that file by file efficient? Wouldn't it be much
>; better to show all the information about a file broken out by revision
> recursively so you can scan the results quickly to see what previous
> releases needs to get pulled so you can compare it against the buggy
> code?
>
> As more and more companies move from other scm systems to subversion
> the custom properties are being utilized to help link the old to the
> new. In the case of our migration from VSS to subversion, Polarion's
> extraction tool placed vss labels in two custom property fields that
>; are tied to the svn revision of a file. All files for that commit got
> the custom properties assigned to it.
>
> Forward development for us isn't a big deal as we will use tags to
> track releases, etc. but we often need to go back in time to pull
>; previous code releases to track down when/where new bugs were
>; introduced. We don't want to have to use vss in conjunction with
>; subversion since the information we need is already in subversion but
> currently impossible to get at using smartsvn.
>
> Does our desire in having the repository browser "show log" display
> all the information it has per revision make more sense now?
>;
>
>
>
.
