Marco Perrando wrote:
> Hi all.
>
> I am experimenting a problem.
>
> I attach a script that creates a new repo and shows it.
>
> In a few words, referring to the exmpale attached
>
> the revision #3 creates a new fil text2.txt in the trunk.
>
> then, a svn cp is made from the local copy, that is at revision #2
> (but having an inner object at #3) and revision #4 is created in the
> branch 1.0
>
> When I try to reconstruct the history from the branch, the revision #3
> is missing!!!
>
> This is annoying because the revision #4 contains, correctly, the file
> commited in revision #3.
>
> Obviously, the problem does not rise if I branch from a completely
> up-to-date local copy.
>
> Then, maybe, it should be advisable
> - or to forbid cp (of folders?) if these are not up-to-date
> - or to make svn find that inner objects DO HAVE a revision number
> between that of the parent folder and the one of the copy (i.e. #3)
>
> Am I wrong? Should I post a bug?
What you've found isn't a bug exactly, but certainly creates a situation
which is hard to explain and difficult to accommodate in the various actions
Subversion permits. Disallowing copies of not-up-to-date sources is one way
to help remedy the problem, but that would have to be implemented
server-side due to race conditions in commit ordering (for URL-to-URL
copies) and the natural delay between copy and commit when doing WC-based
copies.
We definitely don't want Subversion "pretending" that a history gap doesn't
exist, as this can cause it to return incorrect information in certain cases
(such as what happens when a *different* line of history is filling that gap
in the path namespace).
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-11-11 20:18:53 CET