On Tue, May 21, 2013 at 12:50 PM, Andrew Reedick <andrew.reed...@cbeyond.net> 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 lesmikes...@gmail.com