AW: tree conflict deletes files
Hi, Johnea, > Von: johnea [mailto:m...@johnea.net] > > I've administered low volume svn repositories for approx. 7 years, and I'd > like to add my woes to those of other 'tree conflict' victims. > > I have a small repo, to which I am the only one committing. > > On one machine, I created a directory of source in the repo, but did not > add it to the repo. > > I realized I could only build this code on a second machine, so I copied > the files manually (outside of svn) to the second machine, completed the > build, and added the resulting directories and files to the repo and > committed. > > This is were the tears start: I went back to the first machine and > performed an 'svn up' without first deleting the non-version controlled, > non-built, copy of the directory. > > This resulted in a tree conflict, which I was totally unable to resolve. I > moved this entire repo directory aside, and re checked out the entire > repository. > > At this point I thought I had resolved my issues, however when I tried to > update teh second/build machine it also registered a tree conflict. > > Each time I try to update either machine, the update deletes all of the > files from the affected directory, leaving only the empty directory > structure. Then announces that the directory is in tree conflict. > > An attempted: svn resolve --accept=theirs-full DIR, informs me that only - > -accept=working is allowed. However, now svn has deleted all of the files > in the DIR and the working copy is a set of empty directories, so the -- > accept=working now accepts a set of empty directories, marking all of the > files I'm trying to download as Deleted. > > Every time I try to update, the directories are emptied, and my only > option is to accept these now empty directories. > > Somewhow I seem to have gotten svn into some sort of tree-conflict loop. > > I've had to remove and re-check out the repo on both machines to resolve > the issue. This is a modest sized project. If this was a large source > collection (gigabytes), this complete re checkout would be totally > unfeasible. Did you try to do a "svn revert -R" after the update? This will drop all local modifications, but it should save you the hassle of a fresh checkout. > I'm running 1.7.5 svn client on both machines and 1.7.something on the > server. > > Hi, my names johnea, and I'm a tree conflict victim Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: "svn cleanup" fails because it can't find a temp file
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: dinsdag 10 juli 2012 16:52 > To: 'Philip Martin'; 'Johan Corveleyn' > Cc: 'Dave Huang'; users@subversion.apache.org > Subject: RE: "svn cleanup" fails because it can't find a temp file > > > > > -Original Message- > > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > > Philip Martin > > Sent: dinsdag 10 juli 2012 11:20 > > To: Johan Corveleyn > > Cc: Dave Huang; users@subversion.apache.org > > Subject: Re: "svn cleanup" fails because it can't find a temp file > > > > Johan Corveleyn writes: > > > > > I think you should file an issue for the unrecoverable working copy > > > after a "blocked by file-in-use" reverse-merge (maybe also for a > > > normal merge?). It would be nice though if you could come up with a > > > nice reproduction recipe, > > > > Just about any merge will do. repos_diff.c:get_file_from_ra passes NULL > > when calling svn_stream_open_unique and that causes the system > > temporary > > dir to be used--we should be passing the .svn temporary dir. (We should > > probably continue to pass NULL if this is a diff, rather than a merge, > > since the working copy might be read-only.) > > Other part of this problem: shouldn't the install operation be ignored if > the to-be installed file cannot be found? > > The workqueue operation should be restartable, which it won't be if the file > is already moved, but some later operation (like obtaining the timestamp) > fails. The most likely cause for this issue (svn merge applying a 'trivial' merge), is now fixed on trunk and the fix is nominated for backport in r1361119. The less trivial merges already had a similar code path that 'fixed' this problem. Bert
Re: AW: tree conflict deletes files
Thanks for your suggestion Markus! On 2012-07-13 01:16, Markus Schaber wrote: > Hi, Johnea, > >> Von: johnea [mailto:m...@johnea.net] >> >> I've had to remove and re-check out the repo on both machines to resolve >> the issue. This is a modest sized project. If this was a large source >> collection (gigabytes), this complete re checkout would be totally >> unfeasible. > > Did you try to do a "svn revert -R" after the update? This will drop all > local modifications, but it should save you the hassle of a fresh checkout. > > > Best regards > > Markus Schaber > I tried 'svn revert', but without the '-R'. Next time I'll try that. Thanks Again! johnea
Re: How to restore a backup?
On Thu, Jul 12, 2012 at 12:38 PM, Les Mikesell wrote: > You don't really have to do anything except make your hooks and conf > directories look the same as the source did. You probably want to > (snip) Wouldn't you also have to tweak revision 0 props too? Phillip
Re: How to restore a backup?
On Fri, Jul 13, 2012 at 11:14 AM, Phillip Hellewell wrote: > On Thu, Jul 12, 2012 at 12:38 PM, Les Mikesell wrote: >> You don't really have to do anything except make your hooks and conf >> directories look the same as the source did. You probably want to >> (snip) > > Wouldn't you also have to tweak revision 0 props too? I don't think anything else would care about the properties set by svnsync. -- Les Mikesell lesmikes...@gmail.com
RE: If our SVN server is 1.6.12, why don't I see older merge history on elements merged from branch to trunk?
> -Original Message- > From: KARR, DAVID [mailto:dk0...@att.com] > Sent: Thursday, July 12, 2012 11:20 AM > To: Cooke, Mark; users@subversion.apache.org > Subject: RE: If our SVN server is 1.6.12, why don't I see older merge history > on elements merged from branch to trunk? > > > -Original Message- > > From: Cooke, Mark [mailto:mark.co...@siemens.com] > > Sent: Wednesday, July 11, 2012 11:00 PM > > To: users@subversion.apache.org > > Cc: KARR, DAVID > > Subject: RE: If our SVN server is 1.6.12, why don't I see older merge > > history on elements merged from branch to trunk? > > > > > -Original Message- > > > From: KARR, DAVID [mailto:dk0...@att.com] > > > Sent: 12 July 2012 00:39 > > > To: users@subversion.apache.org > > > Subject: If our SVN server is 1.6.12, why don't I see older merge > > > history on elements merged from branch to trunk? > > > > > > It appears that our SVN on our server was recently upgraded from a > > > version before merge history tracking was implemented, to version > > > 1.6.x, where merge history should be available. > > > However, I checked the SVN history for an element that I made > > > changes to on a branch, and I looked at that same element after it > > > was merged (by someone else) to the trunk. My changes are in that > > > file, but the SVN history doesn't include the checkin that I did. > > > Is this simply happening because of how the merge to trunk was done? > > > Is there a particular way that merges have to be done to preserve > > > merge history? > > > > It sounds like you are expecting merge history to magically appear for > > merges done _before_ the server was upgraded? In that case, no, svn > > does not go back and try to re-create history (I suspect that would be > > at best an error-prone exercise) but you should start to see info > > being added going forward. > > I suppose I can see how you would have gotten that impression. > > I'm pretty sure the upgrade was implemented before the recent merge. I > guess I'll need to verify that to be sure. Merge information is written by the client not the server. So, the merge info being there depends on the client version. BOb
RE: If our SVN server is 1.6.12, why don't I see older merge history on elements merged from branch to trunk?
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Friday, July 13, 2012 10:11 AM > To: KARR, DAVID; Cooke, Mark; users@subversion.apache.org > Subject: RE: If our SVN server is 1.6.12, why don't I see older merge > history on elements merged from branch to trunk? > > > > > -Original Message- > > From: KARR, DAVID [mailto:dk0...@att.com] > > Sent: Thursday, July 12, 2012 11:20 AM > > To: Cooke, Mark; users@subversion.apache.org > > Subject: RE: If our SVN server is 1.6.12, why don't I see older merge > history > > on elements merged from branch to trunk? > > > > > -Original Message- > > > From: Cooke, Mark [mailto:mark.co...@siemens.com] > > > Sent: Wednesday, July 11, 2012 11:00 PM > > > To: users@subversion.apache.org > > > Cc: KARR, DAVID > > > Subject: RE: If our SVN server is 1.6.12, why don't I see older > merge > > > history on elements merged from branch to trunk? > > > > > > > -Original Message- > > > > From: KARR, DAVID [mailto:dk0...@att.com] > > > > Sent: 12 July 2012 00:39 > > > > To: users@subversion.apache.org > > > > Subject: If our SVN server is 1.6.12, why don't I see older merge > > > > history on elements merged from branch to trunk? > > > > > > > > It appears that our SVN on our server was recently upgraded from > a > > > > version before merge history tracking was implemented, to version > > > > 1.6.x, where merge history should be available. > > > > However, I checked the SVN history for an element that I made > > > > changes to on a branch, and I looked at that same element after > it > > > > was merged (by someone else) to the trunk. My changes are in > that > > > > file, but the SVN history doesn't include the checkin that I did. > > > > Is this simply happening because of how the merge to trunk was > done? > > > > Is there a particular way that merges have to be done to preserve > > > > merge history? > > > > > > It sounds like you are expecting merge history to magically appear > for > > > merges done _before_ the server was upgraded? In that case, no, > svn > > > does not go back and try to re-create history (I suspect that would > be > > > at best an error-prone exercise) but you should start to see info > > > being added going forward. > > > > I suppose I can see how you would have gotten that impression. > > > > I'm pretty sure the upgrade was implemented before the recent merge. > I > > guess I'll need to verify that to be sure. > > Merge information is written by the client not the server. So, the > merge info being there depends on the client version. > > BOb Isn't it really both sides, however? The client may write the information, but if the repository isn't configured for merge tracking, it won't store that info. Is that correct?
RE: If our SVN server is 1.6.12, why don't I see older merge history on elements merged from branch to trunk?
> -Original Message- > From: KARR, DAVID [mailto:dk0...@att.com] > Sent: Friday, July 13, 2012 2:56 PM > To: users@subversion.apache.org > Subject: RE: If our SVN server is 1.6.12, why don't I see older merge history > on elements merged from branch to trunk? > > > -Original Message- > > From: Bob Archer [mailto:bob.arc...@amsi.com] > > Sent: Friday, July 13, 2012 10:11 AM > > To: KARR, DAVID; Cooke, Mark; users@subversion.apache.org > > Subject: RE: If our SVN server is 1.6.12, why don't I see older merge > > history on elements merged from branch to trunk? > > > > > > > > > -Original Message- > > > From: KARR, DAVID [mailto:dk0...@att.com] > > > Sent: Thursday, July 12, 2012 11:20 AM > > > To: Cooke, Mark; users@subversion.apache.org > > > Subject: RE: If our SVN server is 1.6.12, why don't I see older > > > merge > > history > > > on elements merged from branch to trunk? > > > > > > > -Original Message- > > > > From: Cooke, Mark [mailto:mark.co...@siemens.com] > > > > Sent: Wednesday, July 11, 2012 11:00 PM > > > > To: users@subversion.apache.org > > > > Cc: KARR, DAVID > > > > Subject: RE: If our SVN server is 1.6.12, why don't I see older > > merge > > > > history on elements merged from branch to trunk? > > > > > > > > > -Original Message- > > > > > From: KARR, DAVID [mailto:dk0...@att.com] > > > > > Sent: 12 July 2012 00:39 > > > > > To: users@subversion.apache.org > > > > > Subject: If our SVN server is 1.6.12, why don't I see older > > > > > merge history on elements merged from branch to trunk? > > > > > > > > > > It appears that our SVN on our server was recently upgraded from > > a > > > > > version before merge history tracking was implemented, to > > > > > version 1.6.x, where merge history should be available. > > > > > However, I checked the SVN history for an element that I made > > > > > changes to on a branch, and I looked at that same element after > > it > > > > > was merged (by someone else) to the trunk. My changes are in > > that > > > > > file, but the SVN history doesn't include the checkin that I did. > > > > > Is this simply happening because of how the merge to trunk was > > done? > > > > > Is there a particular way that merges have to be done to > > > > > preserve merge history? > > > > > > > > It sounds like you are expecting merge history to magically appear > > for > > > > merges done _before_ the server was upgraded? In that case, no, > > svn > > > > does not go back and try to re-create history (I suspect that > > > > would > > be > > > > at best an error-prone exercise) but you should start to see info > > > > being added going forward. > > > > > > I suppose I can see how you would have gotten that impression. > > > > > > I'm pretty sure the upgrade was implemented before the recent merge. > > I > > > guess I'll need to verify that to be sure. > > > > Merge information is written by the client not the server. So, the > > merge info being there depends on the client version. > > > > BOb > > Isn't it really both sides, however? The client may write the information, > but > if the repository isn't configured for merge tracking, it won't store that > info. > Is that correct? No that's not correct. I think there is some optimization with merges when you have the newer version of the server, ie, it won't send back un-needed revs or something. But, all merge tracking is are svn properties which the previous server version certainly support. What version of the server are you running? BOb
Need advise for branching/tagging/trunking an entirely new revision of trunk
We have been building and maintaining our project for 18 months in SVN "/mycompany/m.example.com/trunk". Current revision is @r3881. Now we want to re-design. This includes directory structures, files, code, etc. I was thinking we just want to shove everything that is now 'trunk' into a 'branch' and start with a clean slate in 'trunk'. Everyone will re-checkout and we will re-export on the production server too. We are only 3 developers, so impact is minimal whatever we decide. [a] is this advisable? if not, what is the proper way to do this? [b] what would be the SVN commands to accomplish this? [c] we've never done any branching or tagging before. We simply use SVN for the very basics to commit, revert, archive/backup, export/checkout, etc... We're running Subversion 1.6.16 if that matters.
Re: Need advise for branching/tagging/trunking an entirely new revision of trunk
On Fri, Jul 13, 2012 at 8:56 PM, Daevid Vincent wrote:
> We have been building and maintaining our project for 18 months in SVN
> "/mycompany/m.example.com/trunk".
> Current revision is @r3881.
>
> Now we want to re-design. This includes directory structures, files, code,
> etc.
>
> I was thinking we just want to shove everything that is now 'trunk' into a
> 'branch' and start with a clean slate in 'trunk'. Everyone will re-checkout
> and we will re-export on the production server too. We are only 3
> developers, so impact is minimal whatever we decide.
>
> [a] is this advisable? if not, what is the proper way to do this?
>
> [b] what would be the SVN commands to accomplish this?
>
> [c] we've never done any branching or tagging before. We simply use SVN for
> the very basics to commit, revert, archive/backup, export/checkout, etc...
>
> We're running Subversion 1.6.16 if that matters.
>
>
What I usually do and advise, even when just myself, is to copy the trunk
to a 'restructure' branch, make the changes there, then if bugs need to be
fixed on the trunk, they can be and then merged to the restructure branch.
Then when completed, you merge everything back to the trunk. Files that
you've moved or deleted would be updated on the trunk and you still have
the history of the changes that you made on the branch before the merge.
For this, you would run:
svn copy URL/trunk URL/branches/restructure-20120713
svn checkout URL/branches/restructure-20120713 restructure-branch
{do your restructuring in restructure-branch}
svn merge URL/branches/restructure-20120713 trunk
svn comit -m "Product code restructuring" trunk
There are very few instances where I do a 'move' to replace the trunk.
That breaks a lot of continuity (history is broken, for example).
Even if you are starting from scratch, I still advise the process above:
Copy -> Restructure -> Merge. In this case, after the copy, there is a
remove of the copy's contents, but that would get propagated to the trunk
on the merge.
-Arcege
--
What comes after the O-nut?
The P-nut
What comes after the P-nut?
The elephant
*joke told by my sons*
