On Aug 16, 2009, at 03:56, Jan Hendrik wrote:
> From old days I have a frameset in one website project, consisting
> of exactly three files:
>
> lecture.php (a HTML frameset)
> content.php
> footnotes.php
[snip]
> we want to get rid of that frameset and join the files into one, e.g.:
>
> -- append footnotes.php to content.php;
> -- overwrite lecture.php with the joined stuff
>
> But we would like to have this new lecture.php having the history of
> its anchestors, too! Just merged into one big history like the files
> were merged into one. Is that possible at all?
In short, no. You can combine the other files into lecture.php by any
means you like, but when you use "svn log" on it, it will show the
history of lecture.php, and will not show the history of
footnotes.php or content.php.
> AFAICS I can copy content & footnotes onto lecture and state that
> in the commit message. Or I can svn delete lecture.php, copy
> footnotes to content and svn rename this to a new lecture.php. Yet
> either way I will lose direct access to the history of at least one of
> the old files.
Yes, that's how it is. I know of no workaround.
> I know the notion about no history is lost with Subversion. I also
> know about these pig_at_revisions, though failing myself to really
> understand them from reading the book a while ago, yet this is for
> content writers/editors, not programmers. I am not even sure these
> special (super?) revisions can be accessed from the GUI tools
> (mostly Tortoise) they use at all.
Peg revisions are not special or super revisions. They are your
regular and ordinary revisions. There are just two ways of having
Subversion use them: the usual way is called operative revisions and
has the syntax "-r OPREV". The peg revision syntax is "@PEGREV" at
the end of a URL. Consider:
svn cat -r OPREV url://to/file_at_PEGREV
It means: Go to revision PEGREV in the repository and get the object
known at that time as "file". Then display revision OPREV of that
object. This is useful if "file" was deleted at some point, then
recreated anew later or copied from an entirely different object. The
peg revision allows you to specify that you want the older object by
the same name, not the object by that name that's currently there.
Peg revisions are also good for examining objects which have been
deleted from the HEAD. For example, if in revision 500 you delete
content.php but you later want to go back and examine its log, you can
svn log url://to/content.php_at_499
You specify a peg revision in which the file still existed (so
anything between the time the file was created and 499, since in 500
it's gone). If you don't specify a peg revision, it defaults to HEAD,
so "svn log url://to/content.php" (without a peg revision) won't work
if you've deleted content.php from the HEAD.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2384105
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-16 21:21:15 CEST