svn merger error- Unreadable path encountered; access denied
Hi, I am trying out svn branching and merging. I have a repository named MyRepo, to create a branch I have done the following Structure of MyRepo is as follows = MyRepo -> Branch -> Trunk -> Tags First checked out the repository svn checkout svn://svnserver/MyRepo Then created a branch using == svn copy svn://svnserver/MyRepo/trunk svn://svnserver/MyRepo/Branch/TestMerge -m "test merging" Then checked out the new branch to a new location (E:\br) === svn checkout svn://svnserver/MyRepo/Branch/TestMerge Then Added a new file to this TestMerge folder, then added in to the svn using svn add command, then commited it to the server. Now I want to merge this change to the trunk using svn merge command, for that I have checked out a new working copy (E:\ch), then executed the merge command svn merge svn://svnserver/MyRepo/Branch/TestMerge svn://svnserver/MyRepo/trunk E:\ch\Trunk But I get the following error, what am I doing wrong? "svn: Unreadable path encountered; access denied" Thanks, Lloyd
Re: svn merger error- Unreadable path encountered; access denied
Am 13.01.2012 10:05, schrieb Lloyd: I am trying out svn branching and merging. I have a repository named MyRepo, to create a branch I have done the following Structure of MyRepo is as follows = MyRepo -> Branch -> Trunk -> Tags First checked out the repository svn checkout svn://svnserver/MyRepo Why? You're just adding overhead by checking out the whole content of the repository, including all branches and all tags. Generally, the advise is to check out a working copy for just the part you are planning to work on. I typically have a handful of trunk checkouts, one of each major release branch and the tags only when I'm building binaries (which I don't, the nightly autobuild does that here). Then created a branch using == svn copy svn://svnserver/MyRepo/trunk svn://svnserver/MyRepo/Branch/TestMerge -m "test merging" Then checked out the new branch to a new location (E:\br) === svn checkout svn://svnserver/MyRepo/Branch/TestMerge Similarly, why? You have a working copy containing the whole repository. If you updated that working copy, it would pull the newly created folder already. Also, something I can't tell from the info provided, if you check out working copies on top/inside each other, you are up for trouble. Then Added a new file to this TestMerge folder, then added in to the svn using svn add command, then commited it to the server. Now I want to merge this change to the trunk using svn merge command, for that I have checked out a new working copy (E:\ch), Again, one more working copy unnecessarily, as you already have one for the trunk where you can do stuff. then executed the merge command svn merge svn://svnserver/MyRepo/Branch/TestMerge svn://svnserver/MyRepo/trunk E:\ch\Trunk But I get the following error, what am I doing wrong? "svn: Unreadable path encountered; access denied" "Trunk" is not the same as "trunk", SVN is case sensitive. BTW: There are repository-side configurations that disallow commits that would add files that only differ by their case. A directory containing such files would be impossible to check out on MS Windows. Generally, since you are using MS Windows, I'd suggest using TortoiseSVN, as it provides a friendlier interface where you simply pick the path from a list instead of manually (mis-)typing it. ;) Greetings! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: svn merger error- Unreadable path encountered; access denied
Thanks Uli. This is what I understood when reading the subversion book. If you were in my position, what would you have done? A simple example would be much more helpful than an explanation. And that "lower case" was a typo in the mail. And also I have few questions:- Should I be checking out only trunk or only the branch I have to work. Am I doing anything wrong in creating the branch (I did as per the book said)? Thank you very much, Lloyd On Fri, Jan 13, 2012 at 5:04 PM, Ulrich Eckhardt < ulrich.eckha...@dominolaser.com> wrote: > Am 13.01.2012 10:05, schrieb Lloyd: > > I am trying out svn branching and merging. I have a repository named >> MyRepo, to create a branch I have done the following >> >> Structure of MyRepo is as follows >> = >> MyRepo >> -> Branch >> -> Trunk >> -> Tags >> >> First checked out the repository >> >> svn checkout svn://svnserver/MyRepo >> > > Why? You're just adding overhead by checking out the whole content of the > repository, including all branches and all tags. Generally, the advise is > to check out a working copy for just the part you are planning to work on. > I typically have a handful of trunk checkouts, one of each major release > branch and the tags only when I'm building binaries (which I don't, the > nightly autobuild does that here). > > > > Then created a branch using >> == >> >> svn copy svn://svnserver/MyRepo/trunk >> svn://svnserver/MyRepo/Branch/**TestMerge -m "test merging" >> >> Then checked out the new branch to a new location (E:\br) >> ==**= >> >> svn checkout svn://svnserver/MyRepo/Branch/**TestMerge >> > > Similarly, why? You have a working copy containing the whole repository. > If you updated that working copy, it would pull the newly created folder > already. Also, something I can't tell from the info provided, if you check > out working copies on top/inside each other, you are up for trouble. > > > > Then Added a new file to this TestMerge folder, then added in to the svn >> using svn add command, then commited it to the server. >> >> Now I want to merge this change to the trunk using svn merge command, for >> that I have checked out a new working copy (E:\ch), >> > > Again, one more working copy unnecessarily, as you already have one for > the trunk where you can do stuff. > > > then executed the merge command >> >> svn merge svn://svnserver/MyRepo/Branch/**TestMerge >> svn://svnserver/MyRepo/trunk E:\ch\Trunk >> >> But I get the following error, what am I doing wrong? >> >> "svn: Unreadable path encountered; access denied" >> > > "Trunk" is not the same as "trunk", SVN is case sensitive. BTW: There are > repository-side configurations that disallow commits that would add files > that only differ by their case. A directory containing such files would be > impossible to check out on MS Windows. > > Generally, since you are using MS Windows, I'd suggest using TortoiseSVN, > as it provides a friendlier interface where you simply pick the path from a > list instead of manually (mis-)typing it. ;) > > > Greetings! > > Uli > > ** > Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland > Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 > > ** > Visit our website at http://www.dominolaser.com > > ** > Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten > bestimmt und kann vertrauliche Informationen enthalten. Bitte > benachrichtigen Sie den Absender umgehend, falls Sie nicht der > beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu > löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder > anderweitig benutzt werden. > E-Mails können durch Dritte gelesen werden und Viren sowie > nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese > Folgen nicht verantwortlich. > > ** > >
Re: svn merger error- Unreadable path encountered; access denied
Am 13.01.2012 13:32, schrieb Lloyd: A simple example would be much more helpful than an explanation. And that "lower case" was a typo in the mail. ..would have been too easy, eh? ;) Anyhow, I think I know what's wrong: >>> svn merge svn://svnserver/MyRepo/Branch/**TestMerge >>> svn://svnserver/MyRepo/trunk E:\ch\Trunk >>> >>> But I get the following error, what am I doing wrong? >>> >>> "svn: Unreadable path encountered; access denied" I think you simply have the two source paths in the wrong order. The first one should be the origin and the second one the one with the modifications, which are then merged into the third one. Note that the reverse order is not wrong per se, "reverse merging" to remove a change is a feature. Should I be checking out only trunk or only the branch I have to work. Actually, we here (5 people in adjacent rooms) commit to trunk directly. This means that changes are tested by others earlier. It also causes a few issues now and then, but they are easy to resolve because they are still fresh. If you find someone elses commit causes problems, you can simply "svn update -r" to an earlier revision and tell the person about the problem. We only create feature branches for really intrusive changes that might be unstable for several commits, and of course release branches to isolate them from later development. Anyway, getting back to your question, the answer is yes. When working on a feature branch, you only check out that branch. Then, in order to merge it back into trunk, you create a separate WC for that. If you then want to merge a bugfix from the trunk to a release branch, you check out a third WC. Note that you can also "svn switch" WCs, which is relatively cheap concerning the bandwidth and time used. Using a simple filesystem copy allows you to rather quickly create a new working copy, which you can then switch to the new location. If you have the whole repo checked out, an update means downloading and storing every single tag and branch, even those you don't work on. Also, you can't use the cheap way to clone a working copy to copy just a part. Am I doing anything wrong in creating the branch (I did as per the book said)? No, creating the branch looks fine. There are other ways, like doing it in the working copy (WC->WC copy) or mixed (WC->URL copy), but all are correct. Good luck! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: Space Constrain
2012/1/13 Thorsten Schöning : > Guten Tag Les Mikesell, > am Donnerstag, 12. Januar 2012 um 18:26 schrieben Sie: > >> We have a lot of component libraries that we >> want to include in larger projects without recompiling each build >> (i.e. we want to run known/tested instances) and have been including >> the binaries in tags so the headers and shared libs are versioned >> together. > > What's your problem at all? That you must version the same pre > compiled libraries as a tag in each of your projects? It is a combination of things. One is the long-ago decision to combine a large number of projects in the same repository. The other is that our QA group wants to test a binary library component thoroughly, then make sure it is re-used instead of recompiled in each project that uses it. Again, a decision made long ago for good reasons at the time, but perhaps less important now that we have more strictly-controlled build processes and environments. > Are the > libraries such big that you run out of space? Not strictly speaking. That is we can deal with the overall disk space and that requirement won't change by breaking things up. However we are at a point where the time to complete a svnadmin dump/load cycle is becoming impractical. I don't like a situation where we can't perform maintenance. >> It''s clearly the wrong thing to do, but it works. > > I don't think so, if it saves you time and guarantees the use of > tested library versions, I would do the same. My in approach in my > company is to use a separate Repository for all kinds of libraries, > just version the source code and each developer has to build them on > his machine on it's own. The IDE just references the built libraries. > But we don't have that many libraries and whenever we can't build any > library on our own, I version them pre compiled, too. Unconstrained growth just seems philosophically wrong - and unsustainable in the long run. It might be tolerable if each component were in its own repository or if subversion had a reasonable approach to removing objects, but I can't change those things. > If one just copiess old library versions on updates etc. one can save > a lot of disk space. > >> How >> can you enforce getting exactly the right things in a parallel >> repository that has only the headers and libs that will work the same >> way for external references? > > Use tags and/or fixed revisions in your external definition. Yes, we don't want to change the process of referencing known versions via svn externals in the upper level projects, we just want the binary objects and the necessary headers to be in a different repository. If everything were java we would probably let maven handle the component object versioning, but we have a mix of projects. We do use jenkins for most build activity, so a custom plugin to tag the build results might handle it without introducing mistakes. -- Les Mikesell lesmikes...@gmail.com
RE: Space Constrain
> 2012/1/13 Thorsten Schöning : > > Guten Tag Les Mikesell, > > am Donnerstag, 12. Januar 2012 um 18:26 schrieben Sie: > > > >> We have a lot of component libraries that we want to include in > >> larger projects without recompiling each build (i.e. we want to run > >> known/tested instances) and have been including the binaries in tags > >> so the headers and shared libs are versioned together. > > > > What's your problem at all? That you must version the same pre > > compiled libraries as a tag in each of your projects? > > It is a combination of things. One is the long-ago decision to combine a > large > number of projects in the same repository. The other is that our QA group > wants to test a binary library component thoroughly, then make sure it is re- > used instead of recompiled in each project that uses it. Again, a decision > made > long ago for good reasons at the time, but perhaps less important now that we > have more strictly-controlled build processes and environments. > > > Are the > > libraries such big that you run out of space? > > Not strictly speaking. That is we can deal with the overall disk space and > that > requirement won't change by breaking things up. > However we are at a point where the time to complete a svnadmin dump/load > cycle is becoming impractical. I don't like a situation where we can't > perform > maintenance. > > >> It''s clearly the wrong thing to do, but it works. > > > > I don't think so, if it saves you time and guarantees the use of > > tested library versions, I would do the same. My in approach in my > > company is to use a separate Repository for all kinds of libraries, > > just version the source code and each developer has to build them on > > his machine on it's own. The IDE just references the built libraries. > > But we don't have that many libraries and whenever we can't build any > > library on our own, I version them pre compiled, too. > > Unconstrained growth just seems philosophically wrong - and unsustainable in > the long run. It might be tolerable if each component were in its own > repository or if subversion had a reasonable approach to removing objects, but > I can't change those things. > > > > If one just copiess old library versions on updates etc. one can save > > a lot of disk space. > > > >> How > >> can you enforce getting exactly the right things in a parallel > >> repository that has only the headers and libs that will work the same > >> way for external references? > > > > Use tags and/or fixed revisions in your external definition. > > Yes, we don't want to change the process of referencing known versions via svn > externals in the upper level projects, we just want the binary objects and the > necessary headers to be in a different repository. If everything were java we > would probably let maven handle the component object versioning, but we > have a mix of projects. We do use jenkins for most build activity, so a > custom > plugin to tag the build results might handle it without introducing mistakes. > Externals can be pinned to a revision in your external repository. Although, it probably makes more sense to use well known paths so if you create a new repository you can duplicate the well known paths by just exporting your HEAD, deleting your repository, recreating it and importing the previous export. You can take this approach for internal and external binary components. Of course, if they are internal components you could include the source to them in your project and just build them with that project. One issue we have is our legacy VB6 dll's that are built on every change. The dll's are put into source since most of our devs don't work on those binaries or can easily compile them. I have found that the bulk of our repo size is due to all these interim build versions. So, these are moved out of the primary source repository and put into a separate repo reference with externals. This repo can be replaced as it grows too big. Now, source controlling external components is a judgement call. It might be better to just leave them in a public network folder and reference those locations in your source projects. Or, you can put them into source control, either the same repo or a separate one. BOb
Re: Space Constrain
2012/1/13 Bob Archer : > > One issue we have is our legacy VB6 dll's that are built on every change. The > dll's are put into source since most of our devs don't work on those binaries > or can easily compile them. I have found that the bulk of our repo size is > due to all these interim build versions. So, these are moved out of the > primary source repository and put into a separate repo reference with > externals. This repo can be replaced as it grows too big. Yes, that is exactly the issue and I don't recall seeing any advice about how to handle it or avoid the problem in the first place. I mostly put off doing anything about it through the subversion 1.4->1.6 revisions while 'obliterate' sounded like a possibility. Now, that doesn't look any closer to reality than it was years ago, so maybe there should be some advice against getting into this situation somewhere for people starting out. > Now, source controlling external components is a judgement call. It might be > better to just leave them in a public network folder and reference those > locations in your source projects. Or, you can put them into source control, > either the same repo or a separate one. Our groups are very distributed and wouldn't all have access to a common file share - and if they did it wouldn't be mapped the same for everyone and wouldn't perform as well as using externals to pull the copies in and update only on changes. We like the functionality, just not the practical issue on the repository side. -- Les Mikesell lesmikes...@gmail.com
Re: Exception...line 673: assertion failed (checksum != NULL)
Hi, I've got exactly the same exception from one of our old wc. I'm not sure what's the reason for cleanup. The wc was update-ed from 1.6 to 1.7 I did found some .svn directories deeper in the directory tree. Maybe the update went wrong? Can I help track this bug down? I'm already using a fresh checkout so I'm going to have the wc around if you wish. Best regards, Peter Balogh On 2012.01.12. 15:07, Andy Levy wrote: Please don't top-post. On Thu, Jan 12, 2012 at 09:02, Greg Townes wrote: Hi Mark Yes, I am asking how to solve this exception. I required a cleanup to get my source code synched with the repository so that I could do a Commit. It should not matter why I needed the cleanup, exceptions should be handled gracefully. I upgraded from 1.7.1 to 1.7.3. It does matter why you needed the cleanup, because different reasons for the cleanup may trigger different conditions (and thus bugs) in the cleanup code. From: "Cooke, Mark" To: Greg Townes; "users@subversion.apache.org" Sent: Thursday, 12 January 2012, 15:29 Subject: RE: Exception...line 673: assertion failed (checksum != NULL) Hello, Tried to do a cleanup on my folders and got this message. 'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\workqueue.c' line 673: assertion failed (checksum != NULL) Are you asking for help? In which case, what were you doing that required a cleanup? Had you upgraded a pre-1.7 working copy by any chance? I think the last developer left hardcoded lines in the code as there is a reference to a "D" drive followed by the path of Development... I do not have that path on my pc. FYI: That path is from the original source of your subversion client (TortoiseSVN) and helps to identify where the error was trapped, it is nothing to do with your code. Regards Greg Townes ~ mark c
Re: Exception...line 673: assertion failed (checksum != NULL)
2012/1/13 Balogh Péter : > I've got exactly the same exception from one of our old wc. > I'm not sure what's the reason for cleanup. > The wc was update-ed from 1.6 to 1.7 > I did found some .svn directories deeper in the directory tree. > Maybe the update went wrong? > Can I help track this bug down? > I'm already using a fresh checkout so I'm going to have the wc around if you > wish. Are those subdirectories related to svn external references? Someone here reported a similar issue some time after the main part of the wc should have been upgraded so I was wondering if it doesn't recurse into the external part until there is a change. -- Les Mikesell lesmikes...@gmail.com
