[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Post merge extra files/folders modified

From: Brendan Dowds <brendan.dowds_at_sciencesoft.com>
Date: Mon, 30 Nov 2009 16:14:24 -0000

Dear Subversion users,


I have a slight problem with my repository that I am unsure how to fix.
Let me first point out I am by no means an expert on Subversion or
version control generally but in my workplace I am the best of a bad
bunch and hence the designated 'administrator' of all things repository


We have been using repositories for our source code for a couple of
years now and are reaping the benefits. To reap yet more benefits we
recently upgraded to 1.6.* to take advantage of the merge log
information as we frequently do merges.


(I'm not sure if this small side point is a bug or our incorrect use of
this feature but when we do a check for modifications after a merge we
get multiple entries for a file e.g. /path/to/file/modified.txt,
path/to/modified.txt, path/modified.txt, modified.txt, where only the
first entry exists. Committing all these doesn't create the extra files,
and in fact doesn't appear to cause any issues, however, it may be
related to my main issue below, I'm not sure)


But we now find ourselves in the position that when a user merges from a
branch into the trunk (both of which are fully up to date and without
any modifications), the test merge and merge shows that only n files
have changed. All well and good so far.


But when the user goes to commit the changes (or does a check for
modifications) in their working copy the list of modifications shows the
same n files, the change folders they reside in (with the revision
number change for the merge log information) AND some other files and


It is these extra files and folders that are the issue.


None of the files actually have changes to their content, all the
changes are to do with the revision number in the merge information, if
you get what I mean.


Having traced these files back I found out some more information. Which
is as follows.


One of the extra files was accidentally deleted from the trunk when a
user reintegrated a branch, call it branch2. This occurred as before he
reintegrated, he merged all the recent changes from the trunk into his
working copy of branch2, which included the addition of the file in
question. The file in question was originally created in branch1 and
merged into the main trunk without issue. He then made a mistake and
reverted his working copy of branch2 (deleting the file information from
his branch but not the actually file) and repeated the merge. This
second merge obviously gave a conflict which he overlooked, so the file
never existed in the subversion sense in his branch. Meaning when he
reintegrated branch2 back in to the trunk the file was deleted from the
trunk of the repository.


This mistake was noticed within a few revisions and the accidentally
deleted files were restored (using the 'Revert changes from this
revision' option in the TortoiseSVN log window on just those files).


Since then however, whenever some attempts to merge some changes from
the main trunk into their branch those deleted files appear as a
modification, and the only thing that has changed is the associated
revision numbers.


Further investigation found something else. Another user merged from the
main trunk into their feature branch, branch3 (branch3 was made after
the file was added by the merge from branch1 into the trunk, but before
the merge from the trunk into branch2 or the following reintegration of
branch2 into the trunk). Again this created the file additional files,
and the associated information, then committed the changes from this
merge to their branch. So for one of the created files we get a
difference in the merge information of e.g.




He then reintegrated the feature branch (branch3) back into the trunk,
and in the commit following it which is the very next revision in the
repository we get the following merge information:





The version number that has been removed (2912) is the very revision
that restored this file after it was accidentally deleted by the first
user when reintegrating their branch. I think this is a bit more than a
coincidence. Is this removal correct? If so how?


But more importantly, how do we stop the additional files and folders
appearing as modifications after a merge now? As the file contents have
not changed this is more of an annoyance than anything else at the
moment but it is an annoyance that is growing. I think that forcing the
2912 revision number back into the merge information may resolve the
issue, but I'm wary to do this for several reasons, firstly I'm not
entirely sure how, secondly I'm worried I may corrupt our repository,
and thirdly whilst I may correct the issue between one branch and the
trunk I may be propagating it to another branch and the trunk.


Any assistance would be greatly appreciated. Many thanks in advice.


PC and version info

OS: Vista Ultimate 64-bit

Subversion: 1.6.6 (Slik-Subversion x64)

TortoiseSVN: 1.6.6, Build 17493 - 64 Bit


However the same problems arise for people using Vista Ultimate 32-bit,
XP Pro, Subversion & TortoiseSVN 1.6.3 and 1.6.4 (everyone is post 1.6
for Subversion and TortoiseSVN)






Brendan Dowds PhD

Software Development Engineer

Sciencesoft Ltd

Moorpark House

11 Orton Place

Glasgow G51 2HF

United Kingdom


Tel: +44 (0)141 445 0330

Fax: +44 (0)141 445 2041

EM: brendan.dowds_at_sciencesoft.com <mailto:brendan.dowds_at_sciencesoft.com>


PLEASE NOTE: This message, along with any attachments, may be
confidential or legally privileged. It is intended only for the named
person(s), who is/are the only authorised recipients. If this message
has reached you in error, kindly destroy it without review and notify
the sender immediately. Thank you for your help.


The registered address of Sciencesoft Ltd:

Moorpark House, 11 Orton Place, Glasgow G51 2HF, UK Company
registration: SC157594


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email


Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-30 17:22:29 CET

This is an archived mail posted to the Subversion Users mailing list.