Re: svn issue
On May 9, 2013, at 00:16, Amit Kumar wrote: Thanks for reply. But in my condition there are 77 items are in parent folder which is group of project and some other folder like image location, document location. All project folder is required except like documents and image folder. so I have to check out from parent folder only. Sometimes other team create new project. If I take full update then only all project will come in my local or all will update including new project. I want to lock some folder and then I want take full update and I want to update only project folder. Well lock isn't the term for this concept in Subversion. What you're looking for is a sparse working copy.
Re: svn issue
On 05/09/2013 10:46 AM, Amit Kumar [IN7537] wrote: Hi les, Thanks for reply. But in my condition there are 77 items are in parent folder which is group of project and some other folder like image location, document location. All project folder is required except like documents and image folder. so I have to check out from parent folder only. Sometimes other team create new project. If I take full update then only all project will come in my local or all will update including new project. Let us assume you have a file structure like, /trunk | |- proj1 | |- file1 |- file2 |- proj2 |- file3 |- file4 |- proj3 | | |- proj77 |- documents |- images Since you wanted to restrict access to 'documents' directory, you can have access rules like, [reponame:/trunk/documents] user= [reponame:/trunk/proj-created-by-other-team] user= [reponame:/trunk] *=rw I want to lock some folder and then I want take full update and I want to update only project folder. I don't understand the scenario you described. You can restrict access to a folder by the above said method and also grant full access by just user=rw. If you wanted to update only only project folder, you can do so by, $ svn update project-folder --prabhugs Regards, Amit kumar -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Wednesday, May 08, 2013 7:22 PM To: Amit Kumar [IN7537] Cc: users@subversion.apache.org; amitsinghra...@gmail.com Subject: Re: svn issue On Wed, May 8, 2013 at 2:25 AM, Amit Kumar [IN7537]amit_ku...@mindtree.com wrote: I found an issue in SVN. Suppose there are 10 project is in directory. And I want to update only 9 project. There is no option to lock one project not to update. By this issue I get problem. I will request you to solve this issue. Why is that a problem? You should be able to commit to any part you want unless access control blocks it. And normally you would only check out the project(s) that you are working on in the first place. Or are you talking about the revision numbers being global for the repository? That's just the way subversion works - and a feature. -- Les Mikesell lesmikes...@gmail.com http://www.mindtree.com/email/disclaimer.html
Re: svn issue
On Thu, May 9, 2013 at 12:16 AM, Amit Kumar [IN7537] amit_ku...@mindtree.com wrote: Thanks for reply. But in my condition there are 77 items are in parent folder which is group of project and some other folder like image location, document location. All project folder is required except like documents and image folder. so I have to check out from parent folder only. Sometimes other team create new project. If I take full update then only all project will come in my local or all will update including new project. I want to lock some folder and then I want take full update and I want to update only project folder. I see others have described how to get a sparse working copy but personally I'd rearrange the repository layout to match the structure so you can check out one top level directory and get what you want. If that is the way everyone uses the repository, perhaps you could move the 77 things you want under a new upper-level directory parallel to the one you don't want. Or, if everyone uses different parts, group them under directories that match the use patterns, then add a new directory that you check out containing svn externals that pull the other components into the right places and others can do the same for their own layouts. The bad (or good, depending on your use patterns and tools...) side of externals is that commits don't automatically recurse into the folders pulled through external references. Checkouts and updates follow them automatically, but you have to explicitly commit changes separately. Externals also make it much easier to work with separate trunk/branches/tags folders at project-level folders for various components with separately-managed component releases, but it doesn't sound like you are using that convention in your repository now. -- Les Mikesell lesmikes...@gmail.com
RE: How to remove revision number in mergeinfo eligible list
From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, May 08, 2013 8:25 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: How to remove revision number in mergeinfo eligible list Hi Andrew Thanks for taking the time to respond. We did as told step by step and the result is the same - revision number is still in eligible list at the final step [root@host newbranchWC]# svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk r6554 r9946 [root@host newbranchWC]# svn propget svn:mergeinfo . /root/trunk:6560,9804,9806,9836,9874-9876,9880-9881,9899-9900,9951-9952 [root@host newbranchWC]# svn merge -c 6554 --record-only https://some.url.com/svn/root/trunk [root@host newbranchWC]# svn propget svn:mergeinfo . /root/trunk:6560,9804,9806,9836,9874-9876,9880-9881,9899-9900,9951-9952 [root@host newbranchWC]# svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk r6554 r9946 We wonder if it has to do with the rev number change itself. That 6554 rev number is about /root/Trunk creation from svn mkdir The following rev number 6560 is about renaming /root/Trunk to /root/trunk Then the following rev number 9804 is about svn copy of dir A to https://some.url.com/svn/root/trunk/A Then the following rev number 9806 is about svn copy of dir B to https://some.url.com/svn/root/trunk/B Would such actions impact the very first rev number for folder https://some.url.com/svn/root/Trunk ? We use SVN 1.6 The good news is that I was able to do a merge that produced output similar to yours. The bad news is that you are probably merging unrelated branches... What branch is your workspace set to? (svn info) And what is the common ancestor between /root/Trunk and the workspace branch? You can try 'svn merge --ignore-ancestry', but I don't think it will make a difference since your branches are probably very unrelated. In other words, 'svn merge' should have produced some output. The fact that it didn't implies that there was no merging to be done. I have no idea why 'svn mergeinfo --show-rev eligible' would still list revs.
svn log -v path problems
Users, I am working on extracting the the files that are added and deleted using svn log -v from the koffice subversion repository. The repository is : svn://anonsvn.kde.org/home/kde/trunk/koffice/ The specific problem is at. svn log -v -r 438825 The problem is that a directory was renamed. So it lists it as deleted and added. D /trunk/koffice/krita/plugins/filterspreview A /trunk/koffice/krita/plugins/filtersgallery There were other files in the directory that were deleted, but they have the wrong directory name D /trunk/koffice/krita/plugins/filtersgallery/kis_dlg_filterspreview.cc Thank You Decker
Re: svn log -v path problems
Michael Decker wrote on Thu, May 09, 2013 at 12:00:12 -0400: Users, I am working on extracting the the files that are added and deleted using svn log -v from the koffice subversion repository. The repository is : svn://anonsvn.kde.org/home/kde/trunk/koffice/ The specific problem is at. svn log -v -r 438825 The problem is that a directory was renamed. So it lists it as deleted and added. D /trunk/koffice/krita/plugins/filterspreview A /trunk/koffice/krita/plugins/filtersgallery There were other files in the directory that were deleted, but they have the wrong directory name D /trunk/koffice/krita/plugins/filtersgallery/kis_dlg_filterspreview.cc Why do you think that is wrong? That's a perfectly valid history. Compare: svnadmin create r svn co file://`pwd`/r wc cd wc svn mkdir A touch A/mu A/mu2 svn add A/mu A/mu2 svn ci -mr1 svn up svn rename A B svn rm B/mu B/mu2 svn cp file://`cd .. pwd`/A/mu2@1 B/mu2 svn ci -mr2 svn up svn log -qvr2 Thank You Decker
Re: svn log -v path problems
On Thu, May 09, 2013 at 12:00:12PM -0400, Michael Decker wrote: Users, I am working on extracting the the files that are added and deleted using svn log -v from the koffice subversion repository. The repository is : svn://anonsvn.kde.org/home/kde/trunk/koffice/ The specific problem is at. svn log -v -r 438825 The problem is that a directory was renamed. So it lists it as deleted and added. D /trunk/koffice/krita/plugins/filterspreview A /trunk/koffice/krita/plugins/filtersgallery There were other files in the directory that were deleted, but they have the wrong directory name D /trunk/koffice/krita/plugins/filtersgallery/kis_dlg_filterspreview.cc Thank You Decker I'm not entirely sure what your question is. You were saying you want to 'extract' files. What does that mean exactly? Perhaps you are simply confused by the output produced by 'svn log -v' and you want an explanation? Here's the output, for reference: $ svn log -v -r438825 svn://anonsvn.kde.org/home/kde/trunk/koffice/ r438825 | berger | 2005-07-26 10:31:46 +0200 (Tue, 26 Jul 2005) | 2 lines Changed paths: M /trunk/koffice/krita/plugins/Makefile.am A /trunk/koffice/krita/plugins/filtersgallery (from /trunk/koffice/krita/plugins/filterspreview:438097) R /trunk/koffice/krita/plugins/filtersgallery/Makefile.am (from /trunk/koffice/krita/plugins/filterspreview/Makefile.am:438604) A /trunk/koffice/krita/plugins/filtersgallery/filters_gallery.cc (from /trunk/koffice/krita/plugins/filterspreview/filterspreview.cc:436897) A /trunk/koffice/krita/plugins/filtersgallery/filters_gallery.h (from /trunk/koffice/krita/plugins/filterspreview/filterspreview.h:436897) D /trunk/koffice/krita/plugins/filtersgallery/filterspreview.cc D /trunk/koffice/krita/plugins/filtersgallery/filterspreview.h A /trunk/koffice/krita/plugins/filtersgallery/kis_dlg_filtersgallery.cc (from /trunk/koffice/krita/plugins/filterspreview/kis_dlg_filterspreview.cc:436897) A /trunk/koffice/krita/plugins/filtersgallery/kis_dlg_filtersgallery.h (from /trunk/koffice/krita/plugins/filterspreview/kis_dlg_filterspreview.h:436897) D /trunk/koffice/krita/plugins/filtersgallery/kis_dlg_filterspreview.cc D /trunk/koffice/krita/plugins/filtersgallery/kis_dlg_filterspreview.h R /trunk/koffice/krita/plugins/filtersgallery/kis_filters_listview.cc (from /trunk/koffice/krita/plugins/filterspreview/kis_filters_listview.cc:438604) R /trunk/koffice/krita/plugins/filtersgallery/kis_filters_listview.h (from /trunk/koffice/krita/plugins/filterspreview/kis_filters_listview.h:438604) A /trunk/koffice/krita/plugins/filtersgallery/kritafiltersgallery.rc (from /trunk/koffice/krita/plugins/filterspreview/kritafilterspreview.rc:437923) D /trunk/koffice/krita/plugins/filtersgallery/kritafilterspreview.rc D /trunk/koffice/krita/plugins/filterspreview change name of a plugin filterspreview to filtersgallery This looks like a rename of a directory which is a mixed-revision working copy, see http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs A rename is represented as a copy and a delete. When a mixed-revision tree is copied, the root node is copied first, and then children are added/deleted to the copy as necessary to ensure that the committed result matches the configuration of the mixed-revision working copy. Usually, a rename like the above would be made without a working copy, by passing URL arguments to svn copy. Or it could be made with a single-revision working copy. In either case, 'svn log -v' would show just two entries, like this: D /trunk/koffice/krita/plugins/filterspreview A /trunk/koffice/krita/plugins/filtersgallery (from /trunk/koffice/krita/plugins/filterspreview:438097) Does this help you?
Re: trunk naming best practice question
On 05/07/2013 04:50 AM, Z W wrote: What's the best practice in use with SVN ? Maybe this can give you some ideas on how to organize your subversion repositories: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.commonpatterns From your description, it sounds like you are trying to implement the release branches approach. -- Zé
Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Problem: Subversion doesn't have branches. Subversion has directory objects, and we Humans(tm) arbitrarily decide that some directories are branches, thereby giving these directories (branches) magical powers and mystical significance. Meanwhile, Subversion grinds on, treating those magic branches as mundane directories. You can see the effects of this problem when you change a parent directory common to multiple branches, e.g. changing /projectFoo/branches to /projectBar/branches will cause every branch in /projectBar/branches/* to have a shared revision. This complicates finding branch points (--stop-on-copy), finding the common ancestor, etc.. Are there any plans to address this issue or otherwise make branches a first class object? Or at least add a switch to 'svn log' to skip over extraneous only the parent dir path changed revisions? Demonstration: $ svn mkdir -m ^/project1/branches Committed revision 73. $ svn mkdir -m ^/project1/branches/alpha Committed revision 74. $ svn mkdir -m ^/project1/branches/beta Committed revision 75. $ svn log -q -v ^/project1/branches/alpha r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) | 1 line Changed paths: A /project1/branches/alpha $ svn log -q -v ^/project1/branches/beta r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/beta As you can see from the svn logs, the alpha and beta branches are completely independent. They have no revisions in common. But by renaming the parent project1 dir to project100, we create a linkage between the two: $ svn mv -m ^/project1 ^/project100 Committed revision 76. $ svn log ^/project100/branches/alpha r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/alpha $ svn log ^/project100/branches/beta r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/beta Note that the independent branches alpha and beta now have revision 76 in common... even though neither branch was changed. Adding insult to injury, svn log --stop-on-copy will stop on revision 76, i.e. it treats r76 as a branch point: $ svn log --stop-on-copy -v ^/project100/branches/alpha r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) $ svn log --stop-on-copy -v ^/project100/branches/beta r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) As you can see, the independent alpha and beta branches now have revision 76 in common. All because Subversion doesn't have branches. /grumble
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 09.05.2013 22:08, Andrew Reedick wrote: Problem: Subversion doesn't have branches. Subversion has directory objects, and we Humans(tm) arbitrarily decide that some directories are branches, thereby giving these directories (branches) magical powers and mystical significance. Meanwhile, Subversion grinds on, treating those magic branches as mundane directories. You can see the effects of this problem when you change a parent directory common to multiple branches, e.g. changing /projectFoo/branches to /projectBar/branches will cause every branch in /projectBar/branches/* to have a shared revision. This complicates finding branch points (--stop-on-copy), finding the common ancestor, etc.. Are there any plans to address this issue or otherwise make branches a first class object? Or at least add a switch to 'svn log' to skip over extraneous only the parent dir path changed revisions? Demonstration: $ svn mkdir -m ^/project1/branches Committed revision 73. $ svn mkdir -m ^/project1/branches/alpha Committed revision 74. $ svn mkdir -m ^/project1/branches/beta Committed revision 75. $ svn log -q -v ^/project1/branches/alpha r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) | 1 line Changed paths: A /project1/branches/alpha $ svn log -q -v ^/project1/branches/beta r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/beta As you can see from the svn logs, the alpha and beta branches are completely independent. They have no revisions in common. But by renaming the parent project1 dir to project100, we create a linkage between the two: $ svn mv -m ^/project1 ^/project100 Committed revision 76. $ svn log ^/project100/branches/alpha r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/alpha $ svn log ^/project100/branches/beta r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/beta Note that the independent branches alpha and beta now have revision 76 in common... even though neither branch was changed. Adding insult to injury, svn log --stop-on-copy will stop on revision 76, i.e. it treats r76 as a branch point: $ svn log --stop-on-copy -v ^/project100/branches/alpha r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) $ svn log --stop-on-copy -v ^/project100/branches/beta r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) As you can see, the independent alpha and beta branches now have revision 76 in common. All because Subversion doesn't have branches. Well, given that you have not created any branches, this works as expected :) There are no branch points in your repository; only directories. A branch is created by copying a directory (with svn copy), not by creating it (with svn mkdir), and that is why your --stop-on-copy works the way it does -- the only copy is a side effect of the rename (which is currently represented as copy+delete), hence --stop-on-copy stops ... when it sees the copy. The real problem here is that Subversion does not treat /renames/ as atomic operations. This is indeed being addressed, but a complete solution will take time. I'm not going to go into technical details
Server sent unexpected return value (403 Forbidden) in response to PROPFIND
Hi Team, I'm a newbie in subversion and while trying to checkout source code from an svn repo using svn co i get this error and no file is imported! *[user-V1@master test]$ svn co https://svnserver.mycompany.com/svn/repos/simpeTest/trunk/2_developpement* *svn: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for '/svn/repos/simpeTest/trunk/2_developpement'* Here are the credentials i'm using to access this repo: *Login* : svc-generic *Password *: !SVN2012$ PS: the same command was working, i was able to ckeck out source code with these credentials and this error has just occurs, If you could take a look a this? :) Thanks in advance Regards Mehdi
Logs del crash del slicksvn
Hi, this error has occurred usin svn. It can help you. If you have any information about the cause of the error let me know. Thanks Francisco J. Moreno INDRA E - This application has halted due to an unexpected error. E - A crash report and minidump file were saved to disk, you can find them here: E - C:\DOCUME~1\l679792\LOCALS~1\Temp\svn-crash-log20130507134524.log E - C:\DOCUME~1\l679792\LOCALS~1\Temp\svn-crash-log20130507134524.dmp E - Please send the log file to users@subversion.apache.orgmailto:users@subversion.apache.org to help us analyze E - and solve this problem. E - E - NOTE: The crash report and minidump files can contain some sensitive information E - (filenames, partial file content, usernames and passwords etc.) Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary. svn-crash-log20130507134524.log Description: svn-crash-log20130507134524.log svn-crash-log20130507134524.dmp Description: svn-crash-log20130507134524.dmp
Re: Server sent unexpected return value (403 Forbidden) in response to PROPFIND
Hi Mehdi, Are you sure you have read access to this part of your repo? You mention the same command was working and you checked out some code but I'm not sure if you're trying to check the same code. If you are trying to check out from the same part of your repository as before and you're caching your credentials then it might be worth clearing them by removing the contents of ~/.subversion/auth. Hope this helps, Katherine On Thu, May 9, 2013 at 5:43 PM, Mehdi Hayani hayani.mehdi...@gmail.comwrote: Hi Team, I'm a newbie in subversion and while trying to checkout source code from an svn repo using svn co i get this error and no file is imported! *[user-V1@master test]$ svn co https://svnserver.mycompany.com/svn/repos/simpeTest/trunk/2_developpement* *svn: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for '/svn/repos/simpeTest/trunk/2_developpement'* Here are the credentials i'm using to access this repo: *Login* : svc-generic *Password *: !SVN2012$ PS: the same command was working, i was able to ckeck out source code with these credentials and this error has just occurs, If you could take a look a this? :) Thanks in advance Regards Mehdi
Re: How to use --record-only to unblock
Hi Johan Thanks for responding. If we get a chance we'll let you know. We're tight with time now. Thanks On Wed, May 8, 2013 at 5:25 AM, Johan Corveleyn jcor...@gmail.com wrote: On Wed, May 8, 2013 at 12:51 PM, Z W mpc8...@gmail.com wrote: Hi All We plan to merge from the trunk to a feature branch using --record-only for a few revisions numbers. Is there a way to unblock a revision number after first using --record-only ? Good question, I'm not sure really. Try (in a local working copy, no need to commit, but you can verify the results): cd $working-copy-of-featurebranch svn propget svn:mergeinfo . # Take note of what the mergeinfo looks like ... the revision that you want to unblock should be listed there (either individually, or as part of some range). Now: svn merge --record-only -c-$REV $SOURCE . svn propget svn:mergeinfo . # Take note of what the mergeinfo looks like ... the revision that you want to unblock should no longer be present in the mergeinfo. Note in the merge step above: '-c-$REV' means a negative revision number (minus the revision), which means that you want to (record-only) merge the reverse of $REV. Can you report back the results to the list? I'm curious whether this works. -- Johan
Re: trunk naming best practice question
Hi Ze, Bob, Les Thanks for writing back. From your experience, with new features being worked on the trunk, and but the planning and sizing is poor during developemnt, when it comes to releasing but the feature is incomplete, how would you turn on or off features development at code-freeze before creating a release branch. Thanks On Thu, May 9, 2013 at 10:21 AM, Zé jose.pas...@gmx.com wrote: On 05/07/2013 04:50 AM, Z W wrote: What's the best practice in use with SVN ? Maybe this can give you some ideas on how to organize your subversion repositories: http://svnbook.red-bean.com/**en/1.7/svn-book.html#svn.** branchmerge.commonpatternshttp://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.commonpatterns From your description, it sounds like you are trying to implement the release branches approach. -- Zé
