>
> I wanted to toss this idea out to the group to see if it has merit.
>
> One of the major drawbacks we've stumbled on is that of how svn show
> log performs on directories with file externals. Show log on
> directories will show that the svn:externals property changed, but
> will not recurse on the file external itself to show the change in the
file.
>
It looks like this may already have been discussed a bit at:
http://svn.haxx.se/tsvn/archive-2010-04/0075.shtml
Stefan^2 stated:
...quote...
First of all, such feature would be at least somewhat useful -
even if the externals point to a other repositories. And it could
be implemented to be almost as fast as 'svn log -v'. There are
a number of pitfalls, though:
* what is the semantics for externals that have been fixed
to a specific revision?
* what is the semantics of "--limit" even for externals
pointing to HEAD in the same repository?
* the result could (probably) not be cached
If other externals to other repositories would be handled as well:
* how do I discern paths coming in from different repositories?
(log format needs to be extended)
* how do the revisions relate to each other (timestamps or revisions?)
Having said all of that, what is your concrete usage scenario -
for externals and how log should behave? There might be a way
to support a specific but sufficiently common use-case on the
client side with acceptable effort.
-- Stefan^2. ...end quote...
My concrete example is that I have a WC full of directories which contains
a large number of file externals with pegged revisions. In fact, almost
all the files in the WC are file externals. All the file externals point
to a database of file "histories" - think of Rational CMVC. Each history
provides another dimension to the filename and revision so you can have
foo.c of history "program a" that can live in different places within the
project hierarchy or be shared by other projects.
So all our files are actually contained in the repo under
http://server/repo/database within folders. The folder names define the
"history" of the file.
^/database/project_a/foo.c
^/database/project_a/bar.c
^/database/project_b/foo.c
Each project will use externals to share/reference files from the
database.
^/projects/project_a/foo.c --> ^/database/project_a/foo.c_at_50
^/projects/project_a/bar.c --> ^/database/project_a/bar.c_at_50
^/projects/project_b/foo.c --> ^/database/project_b/foo.c_at_51
^/projects/project_b/foo.c --> ^/database/project_a/bar.c_at_50
Each user performs normal TSVN updates and commits on the files (if peg ==
head) until they decide to "fork" a history (project_a and _b differ in
requirements for a file).
This is all managed through a lightweight tool that allows users to change
histories and see which files they wish to update (you don't want
project_a to commit a change to foo.c and have it automatically pushed to
project_b, right?)
The major drawback we have now, is that it is very hard to see a changeset
if foo.c and bar.c were updated to implement change request-123. Its easy
to do each file itself (right click, show log), but its currently not
feasible to search teh WC for the impacts from change request-123.
Hope this helps with the usage example and helps builds a alid case for
viewing changes across file externals.
Thanks,
Dan
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3064294
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-09-11 01:34:13 CEST