On Tue, May 21, 2013 at 12:50 PM, Andrew Reedick
<[email protected]> wrote:
>
>> What do you mean by "spurious" log entries? When I look at the log (at
>> least in the tsvn log viewer) I only see revisions that have changes on
>> that path. I don't see every revision number unless I go to the project
>> root path or repository root path.
>>
>
> 1. Create /tags/tag1, /tags/tag2, etc..
> 2. Pretend that your tag1, tag2, etc. dirs are immutable, static, locked
> down, and haven't be touched in months.
> 3. svn log -v --stop-on-copy ^/tags/tag1
> svn log -v --stop-on-copy ^/tags/tag2
> etc.
> 4. # Move your tags dir under a project1 dir
> svn mv -m "" --parents ^/tags ^/project1/tags
What operation would this correspond to in a VCS that had 'first
class' tags? Should svn disallow it to emulate them?
> Ooops. All of your immutable, static, locked down, haven't been touched in
> months tags now have a new revision, and they all share that revision in
> common. The parent dir change from "/tags" to "/project1/tags" is visible
> under the tag1, tag2, etc. baselines because svn doesn't know that
> "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc.
> baselines.
>
> However, the Last Changed Revision of the tag1, tag2, etc. dirs doesn't
> change, so the effect is mostly visual.
Isn't it really just an artifact of using --stop-on-copy to mean
something it doesn't quite mean - or more practically an artifact of
having done a copy that might have been avoided with better planning
or conventions? Is there some documentation that recommends moving
the parent location of the tags after creating them? And again, in a
practical sense, would you prefer for subversion to have disallowed
that move? Or can you at least acknowledge that it didn't force you
to do it?
--
Les Mikesell
[email protected]
