Re: Subversion 1.8.9 repository access issue [Urgent]
On 06.07.2014 23:54, Andreas Stieger wrote: > On 06/07/14 21:58, Branko Čibej wrote: >> On 06.07.2014 13:35, Andreas Stieger wrote: >>> Your repository is of type bdb, (berkeley db backend), not fsfs. As such >>> is it not suitable for a direct upgrade. >> That's nonsense. > See DB_VERSION_MISMATCH and others. Building the bdb backend might just > uncover that. The error in the httpd log is SVN_ERR_FS_UNKNOWN_FS_TYPE. So the part about the BDB back-end not being built is pretty obvious. Berkeley DB databases can always be upgraded from older BDB versions with db_upgrade, if the BDB version on the new server is incompatible with the one on the old server. Nothing else should really matter. We do still support all BDB repositories. We did not deprecate the BDB backend because it would be inherently worse than FSFS, but because we simply do not have the resources to adequately maintain and improve two (and soon, three) repository back-ends. That's all. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Subversion 1.8.9 repository access issue [Urgent]
On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej wrote: > On 06.07.2014 23:54, Andreas Stieger wrote: > > On 06/07/14 21:58, Branko Čibej wrote: > > On 06.07.2014 13:35, Andreas Stieger wrote: > > Your repository is of type bdb, (berkeley db backend), not fsfs. As such > is it not suitable for a direct upgrade. > > That's nonsense. > > See DB_VERSION_MISMATCH and others. Building the bdb backend might just > uncover that. > > > The error in the httpd log is SVN_ERR_FS_UNKNOWN_FS_TYPE. So the part about > the BDB back-end not being built is pretty obvious. > > Berkeley DB databases can always be upgraded from older BDB versions with > db_upgrade, if the BDB version on the new server is incompatible with the > one on the old server. Nothing else should really matter. This is not necessarily reliable. I've encountered at least 4 BDB environments that worked as they were, but for which 'db_upgrade' was impossible. It even paid serious consulting rates while I backported a bunch of CentOS tools to work with an old BDB environment that someone had hand built and not written a usable 'export' function for. I have never found BDB to be stable or reliable enough for production use. > We do still support all BDB repositories. We did not deprecate the BDB > backend because it would be inherently worse than FSFS, but because we > simply do not have the resources to adequately maintain and improve two (and > soon, three) repository back-ends. That's all. Do you intend to discard it in a foreseeable release? While it's been useful to take old SVN environments and be able to run 'svnadmin download' on them with newer Subversion releases, I'm not sure if it's worth just abandoning at some point. Does anyone use it by choice anymore?
Re: Subversion 1.8.9 repository access issue [Urgent]
On 07.07.2014 12:48, Nico Kadel-Garcia wrote: > On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej wrote: >> On 06.07.2014 23:54, Andreas Stieger wrote: >> >> On 06/07/14 21:58, Branko Čibej wrote: >> >> On 06.07.2014 13:35, Andreas Stieger wrote: >> >> Your repository is of type bdb, (berkeley db backend), not fsfs. As such >> is it not suitable for a direct upgrade. >> >> That's nonsense. >> >> See DB_VERSION_MISMATCH and others. Building the bdb backend might just >> uncover that. >> >> >> The error in the httpd log is SVN_ERR_FS_UNKNOWN_FS_TYPE. So the part about >> the BDB back-end not being built is pretty obvious. >> >> Berkeley DB databases can always be upgraded from older BDB versions with >> db_upgrade, if the BDB version on the new server is incompatible with the >> one on the old server. Nothing else should really matter. > This is not necessarily reliable. I've encountered at least 4 BDB > environments that worked as they were, but for which 'db_upgrade' was > impossible. It even paid serious consulting rates while I backported a > bunch of CentOS tools to work with an old BDB environment that someone > had hand built and not written a usable 'export' function for. > > I have never found BDB to be stable or reliable enough for production use. That's an answer to a different question. :) >> We do still support all BDB repositories. We did not deprecate the BDB >> backend because it would be inherently worse than FSFS, but because we >> simply do not have the resources to adequately maintain and improve two (and >> soon, three) repository back-ends. That's all. > Do you intend to discard it in a foreseeable release? While it's been > useful to take old SVN environments and be able to run 'svnadmin > download' on them with newer Subversion releases, I'm not sure if it's > worth just abandoning at some point. Does anyone use it by choice > anymore? http://subversion.apache.org/docs/release-notes/1.8.html#bdb-deprecated I can't predict anything more than what we wrote in the release notes. If we do decide to completely remove BDB support, we will definitely tell our users a couple releases in advance, to give them enough time to migrate. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
How to control access of a subversion repo subfolder via AD groups
Hi, I am trying to setup Subversion authentication through Active Directory authentication and authorization through Active Directory groups.Everything is working fine but the issue I am facing is when I want to restrict access to subdirectorys of a subversion repository. For ex: there is a repo with a name "ankushtest" and it has a subdirectory "test", now I want some users which are in AD group to be able to read or commit to subdirectory "test" only. This access is working fine through SVN clients like Tortoise etc.. but when I try to open the same on a browser, the user which has access only to subdirectory "test" is able to see the all the directorys or files under repo "ankushtest". How this is working is like that, if a user types the complete url for the "test" directory like http://svn.example.com/src/ankushtest/test"; then browser is showing the all the files & directorys of a repo. In the Apache logs I see the below warning whenever I click on the url http://svn.example.com/src/ankushtest/test"; and this test directory on the browser shows all the files & directorys whereas this directory has only 1 file and a sub-directory in it. Mon Jul 07 14:21:47 2014] [warn] mod_dav_svn: nested Location '/src/ankushtest/test' hinders access to 'test1' in SVNPath Location '/src/ankushtest' Environment: Centos 6.5 64-bit with Selinux & Iptables off, Subversion 1.7.17-1(downloaded from the WANDisco site) & Apache version 2.2.15-30 My subversion Configuration file is below LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so LDAPVerifyServerCert off LDAPTrustedMode SSL LDAPTrustedGlobalCert CERT_BASE64 /etc/pki/tls/cert1.pem LDAPTrustedGlobalCert KEY_BASE64 /etc/pki/tls/key1.pem AuthBasicProvider ldap AuthType Basic AuthzLDAPAuthoritative On AuthName "3PG SVN Repository" AuthLDAPURL "ldaps:// 172.16.9.80:3269/DC=exampleC=corp?sAMAccountName?sub?(objectClass=user)"SSL AuthLDAPURL "ldaps:// 172.16.9.90:3269/DC=example,DC=corp?sAMAccountName?sub?(objectClass=user) "SSL AuthLDAPBindDN "auth...@example.corp" AuthLDAPBindPassword ldapsS@1234 Dav svn SVNPATH /home/svn_repos/src/ankushtest Require ldap-group CN=svn_test_ro,OU=test,DC=example,DC=corp Require ldap-group CN=svn_test,OU=test,DC=example,DC=corp # Write access Require ldap-group CN=svn_test,OU=test,DC=example,DC=corp Dav svn SVNPATH /home/svn_repos/src/ankushtest SVNReposName "ankush-2 test repo" Require ldap-group CN=svn_test_b_ro,OU=test,DC=example,DC=corp Require ldap-group CN=svn_test_b_rw,OU=test,DC=example,DC=corp Require ldap-group CN=svn_test,OU=test,DC=example,DC=corp # Write access Require ldap-group CN=svn_test_b_rw,OU=test,DC=example,DC=corp Require ldap-group CN=svn_test,OU=test,DC=example,DC=corp What is the best way to configure and control subfolders access via Active Directory groups so that things works fine in the browser too... Thanks & Regards Ankush Grover
Re: Subversion 1.8.9 repository access issue [Urgent]
On Mon, Jul 7, 2014 at 7:14 AM, Branko Čibej wrote: > On 07.07.2014 12:48, Nico Kadel-Garcia wrote: >> On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej wrote: >>> On 06.07.2014 23:54, Andreas Stieger wrote: >>> Berkeley DB databases can always be upgraded from older BDB versions with >>> db_upgrade, if the BDB version on the new server is incompatible with the >>> one on the old server. Nothing else should really matter. >>> >> This is not necessarily reliable. I've encountered at least 4 BDB >> environments that worked as they were, but for which 'db_upgrade' was >> impossible. It even paid serious consulting rates while I backported a >> bunch of CentOS tools to work with an old BDB environment that someone >> had hand built and not written a usable 'export' function for. >> >> I have never found BDB to be stable or reliable enough for production use. > > That's an answer to a different question. :) Clipping some material: no, it's not a different question. BDB databases *cannot* always be upgraded with db_upgrade, I thought I was clear about that.
Re: Subversion 1.8.9 repository access issue [Urgent]
On 07.07.2014 14:11, Nico Kadel-Garcia wrote: > On Mon, Jul 7, 2014 at 7:14 AM, Branko Čibej wrote: >> On 07.07.2014 12:48, Nico Kadel-Garcia wrote: >>> On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej wrote: On 06.07.2014 23:54, Andreas Stieger wrote: Berkeley DB databases can always be upgraded from older BDB versions with db_upgrade, if the BDB version on the new server is incompatible with the one on the old server. Nothing else should really matter. >>> This is not necessarily reliable. I've encountered at least 4 BDB >>> environments that worked as they were, but for which 'db_upgrade' was >>> impossible. It even paid serious consulting rates while I backported a >>> bunch of CentOS tools to work with an old BDB environment that someone >>> had hand built and not written a usable 'export' function for. >>> >>> I have never found BDB to be stable or reliable enough for production use. >> That's an answer to a different question. :) > Clipping some material: no, it's not a different question. BDB > databases *cannot* always be upgraded with db_upgrade, I thought I was > clear about that. The question that started this thread was why a BDB database could not be opened. The answer is, because the BDB back-end was not built. We don't even know that the old and new BDB versions are different. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Adding [svn users] to subject
Hi Guys Have you thought about adding [svn users] to prefix the subject of emails? It would make my mailbox simpler to prioritise all emails.. Currently I need to read the subjects.. or implement some complex filtering to folder of svn users emails.. Thanks for considering this. Regards Jon
Re: Adding [svn users] to subject
On 07.07.2014 15:23, Notes Jonny wrote: > Hi Guys > Have you thought about adding [svn users] to prefix the subject of emails? Yes, and we shied away from the idea in sheer terror. > It would make my mailbox simpler to prioritise all emails.. Currently > I need to read the subjects.. or implement some complex filtering to > folder of svn users emails.. All messages sent to this list contain the standard list identification header: List-Id: Most mail clients can create filters based on that. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Adding [svn users] to subject
On Mon, Jul 7, 2014 at 2:32 PM, Branko Čibej wrote: > On 07.07.2014 15:23, Notes Jonny wrote: >> Hi Guys >> Have you thought about adding [svn users] to prefix the subject of emails? > > Yes, and we shied away from the idea in sheer terror. > >> It would make my mailbox simpler to prioritise all emails.. Currently >> I need to read the subjects.. or implement some complex filtering to >> folder of svn users emails.. > > All messages sent to this list contain the standard list identification > header: > > List-Id: > > Most mail clients can create filters based on that. Hi Brane Yes, I thought it would have been discussed. As far as I am aware, my client GMail can't add [svn users] to the subject of such emails.
Re: Extend E155021 message to include supported format version
On Mon, Jul 7, 2014 at 9:40 AM, Notes Jonny wrote: > On Fri, Jul 4, 2014 at 4:51 PM, Andy Levy wrote: >> On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny wrote: >>> Hi Mark >>> >>> You are right that I did have 1.8.x installed. Which I downgraded to >>> this version: >>> >>> TortoiseSVN 1.7.7, Build 22907 - 32 Bit , 2012/05/15 12:16:05 >>> Subversion 1.7.5, >>> apr 1.4.6 >>> apr-utils 1.3.12 >>> neon 0.29.6 >>> OpenSSL 1.0.1c 10 May 2012 >>> zlib 1.2.7 >>> >>> NB. I don't know why tortoise is called 1.7.7 and subversion uses >>> 1.7.5 - would be simpler if they matched. >> >> TortoiseSVN release 1.7.7 is built on Subversion version 1.7.5. >> Because there may be bugs in TSVN that aren't present in the >> Subversion libraries, there may be multiple TSVN releases for a given >> version of the Subversion libraries. >> >> For example, TSVN 1.7.2, 1.7.3 & 1.7.4 were all built on Subversion >> 1.7.2; TSVN 1.7.2 had some nasty bugs that needed to be resolved >> quickly (and 1.7.3 had one more). From the release announcement for >> 1.7.3[1]: >> >> Due to some nasty bugs in TortoiseSVN 1.7.2 which in some specific >> situations could make it crash, we're releasing this version out of sync >> with SVN releases. >> >> 1.7.4 had another bug that needed quick resolution[2]. >> >> The alternatives I can think of offhand are: >> >> 1) Only release TSVN in lock-step with Subversion releases, leaving >> TSVN bugs hanging in the wild unnecessarily long >> 2) Don't publish the library versions used in TSVN. This makes >> debugging & error reporting tougher >> 3) Don't bump the TSVN version number. This makes support tougher - >> are we using the first release of 1.7.5 or the second one? >> 4) Add yet another level to the version number scheme? 1.7.5.0, 1.7.5.1, >> etc.? >> >> The current scheme is fine IMHO. >> >> [1]: >> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2894038 >> [2]: >> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2908607 > > Hello > > Many thanks for the replies. > > It sounds like the TortoseSVN team want to keep things roughly "lock > step", I think better to be "completely lock step". > > I would go with: TortoiseSVN_1.7.5_Build001 > > Just increment the Build number when they make an updated delivery of > TortiseSVN that uses svn1.7.5 > > Its more confusing to use a similar but different numbering scheme > (1.7.7 and 1.7.5) in my view. I personally see nothing wrong or confusing about the system the TSVN folks have settled on. If anything, I think your suggestion would lead to more confusion, having to ask people *which* 1.7.5 they're using. What do you mean, 1.7.5 doesn't always mean the same thing? If you'd like to lobby for a change, you'll need to take it to the TSVN mailing list; how TortoiseSVN is managed seems to be quite off-topic on the SVN Users mailing list.
Re: Extend E155021 message to include supported format version
On Fri, Jul 4, 2014 at 4:51 PM, Andy Levy wrote: > On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny wrote: >> Hi Mark >> >> You are right that I did have 1.8.x installed. Which I downgraded to >> this version: >> >> TortoiseSVN 1.7.7, Build 22907 - 32 Bit , 2012/05/15 12:16:05 >> Subversion 1.7.5, >> apr 1.4.6 >> apr-utils 1.3.12 >> neon 0.29.6 >> OpenSSL 1.0.1c 10 May 2012 >> zlib 1.2.7 >> >> NB. I don't know why tortoise is called 1.7.7 and subversion uses >> 1.7.5 - would be simpler if they matched. > > TortoiseSVN release 1.7.7 is built on Subversion version 1.7.5. > Because there may be bugs in TSVN that aren't present in the > Subversion libraries, there may be multiple TSVN releases for a given > version of the Subversion libraries. > > For example, TSVN 1.7.2, 1.7.3 & 1.7.4 were all built on Subversion > 1.7.2; TSVN 1.7.2 had some nasty bugs that needed to be resolved > quickly (and 1.7.3 had one more). From the release announcement for > 1.7.3[1]: > > Due to some nasty bugs in TortoiseSVN 1.7.2 which in some specific > situations could make it crash, we're releasing this version out of sync > with SVN releases. > > 1.7.4 had another bug that needed quick resolution[2]. > > The alternatives I can think of offhand are: > > 1) Only release TSVN in lock-step with Subversion releases, leaving > TSVN bugs hanging in the wild unnecessarily long > 2) Don't publish the library versions used in TSVN. This makes > debugging & error reporting tougher > 3) Don't bump the TSVN version number. This makes support tougher - > are we using the first release of 1.7.5 or the second one? > 4) Add yet another level to the version number scheme? 1.7.5.0, 1.7.5.1, etc.? > > The current scheme is fine IMHO. > > [1]: > http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2894038 > [2]: > http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2908607 Hello Many thanks for the replies. It sounds like the TortoseSVN team want to keep things roughly "lock step", I think better to be "completely lock step". I would go with: TortoiseSVN_1.7.5_Build001 Just increment the Build number when they make an updated delivery of TortiseSVN that uses svn1.7.5 Its more confusing to use a similar but different numbering scheme (1.7.7 and 1.7.5) in my view. Best regards, Jon
Re: Adding [svn users] to subject
On 07.07.2014 15:37, Notes Jonny wrote: > On Mon, Jul 7, 2014 at 2:32 PM, Branko Čibej wrote: >> On 07.07.2014 15:23, Notes Jonny wrote: >>> Hi Guys >>> Have you thought about adding [svn users] to prefix the subject of emails? >> Yes, and we shied away from the idea in sheer terror. >> >>> It would make my mailbox simpler to prioritise all emails.. Currently >>> I need to read the subjects.. or implement some complex filtering to >>> folder of svn users emails.. >> All messages sent to this list contain the standard list identification >> header: >> >> List-Id: >> >> Most mail clients can create filters based on that. > Hi Brane > > Yes, I thought it would have been discussed. As far as I am aware, my > client GMail can't add [svn users] to the subject of such emails. Your client GMail can very easily create filters based on the list ID, and assign labels to the messages that match the filter rules. I should know — I use GMail's filters for exactly that. There's no substantial difference between mangling the subject line and adding labels in GMail; the latter is arguably easier to work with. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Unexpected "svn revert" behavior
I thought I understood status and revert, but the following experience makes me question if I am missing something. I attempted a merge from one branch of our development environment and based on "svn status" after the merge, I had gotten some unexpected results, so I used "svn revert . --recursive" to back out the entire merge. This command reverted a boatload of files that didn't show up in "svn status" moments earlier. That doesn't make sense to me. My understanding is that "svn status" shows all uncommitted changes in the working copy and "svn revert" reverts the uncommitted changes in the working copy by replacing them with the latest revision from the related repository. In the scenario below, the base directory of the working copy for the 'delta' branch of my repository is "/u/delta/cm/40" and that is the current working directory when this set of commands are executed (as you can see in a couple of 'pwd' command outputs). todd@monolith # svn status M . M accountservice/account/guimain.p M accountservice/billing/guimain.p M accountservice/include/showphone.i M accountservice/lib/guimain.p M accountservice/wizard/add/guiwizard.p M insight/export M occupant/assign.i M occupant/display.i M occupant/occupant.f A +reports/aam/include/accessconstants.i A +reports/aam/include/dgtlsubs.i todd@monolith # pwd /u/delta/cm/40 todd@monolith # svn revert . --recursive Reverted '.' Reverted 'renewals/print.p' Reverted 'renewals/undo/guirenewalundo.p' Reverted 'renewals/undo/renewalundo.i' Reverted 'renewals/undo/layout.p' Reverted 'renewals/undo/skip.i' Reverted 'renewals/autorenew/checkpolicy.i' Reverted 'renewals/checkpolicy.i' Reverted 'renewals/ebillbatch/layout.p' Reverted 'renewals/ebillbatch/guiebillbatch.p' Reverted 'renewals/printupdate.p' Reverted 'tools/makedraw/checkroute.i' Reverted 'query/deliverysche.p' Reverted 'query/schedule.i' Reverted 'query/ebillbatch.p' Reverted 'insight/export' Reverted 'Install/load/proto/setupsec.p' Reverted 'Install/40a/postsync/allowdaypass.p' Reverted 'Install/40a/postsync/main.p' Reverted 'Install/40a/postsync/include/contants.i' Reverted 'Install/40a/postsync/include/sysvar.i' Reverted 'Install/40a/presync/main.p' Reverted 'Install/40a/presync/policydel.p' Reverted 'Install/40a/presync/updmenuitem.p' Reverted 'Install/40a/presync/menureseq39.p' Reverted 'occupant/display.i' Reverted 'occupant/occupant.f' Reverted 'occupant/assign.i' Reverted 'pdfinclude/testtexttopdf.p' Reverted 'pdfinclude/oldtexttopdf.p' Reverted 'include/valpullwhere.i' Reverted 'include/campaign/valcampaign.i' Reverted 'include/java/progframe/fillchoice.i' Reverted 'include/balance.i' Reverted 'include/validate/valid.i' Reverted 'include/gui/upddelivsch.i' Reverted 'include/gui/delivschedck.i' Reverted 'include/edit/completestar.i' Reverted 'include/edit/complete.i' Reverted 'include/fix/addmenu.i' Reverted 'setup/campaign/campaign.f' Reverted 'setup/publicat/allowprevdel.p' Reverted 'setup/publicat/daypass.p' Reverted 'setup/combo/valtaxproductid.i' Reverted 'setup/combo/valtaxdistribmeth.i' Reverted 'setup/delivsch/keyprompt.i' Reverted 'accountservice/billing/guimain.p' Reverted 'accountservice/lib/guimain.p' Reverted 'accountservice/include/showphone.i' Reverted 'accountservice/account/guimain.p' Reverted 'accountservice/wizard/add/guiwizard.p' Reverted 'cmshare/adplus/getcampaign.p' Reverted 'cmshare/subscriber/getdelivinfo.p' Reverted 'cmshare/subscriber/getloginsub.p' Reverted 'cmshare/daypass/createdaypass.p' Reverted 'cmshare/daypass/paramtest.i' Reverted 'cmshare/daypass/createdaypassvar.i' Reverted 'cmshare/daypass/password.i' Reverted 'cmshare/daypass/pymtaccept.i' Reverted 'cmshare/daypass/authorize.i' Reverted 'cmshare/daypass/testdaypass.p' Reverted 'cmshare/daypass/dfltrate.p' Reverted 'cmshare/daypass/dfltpymtamt.p' Reverted 'cmshare/daypass/createpymtbatch.i' Reverted 'cmshare/daypass/sendpassword.p' Reverted 'cmshare/daypass/createdaypasstables.i' Reverted 'cmshare/daypass/usageaccept.i' Reverted 'cmshare/daypass/ttsubtaxauthority.i' Reverted 'rating/subscription/makedeal/roundcombotax.i' Reverted 'reports/aam/include/accessconstants.i' Reverted 'reports/aam/include/dgtlsubs.i' Reverted 'reports/aam/dgtlsubaudit/var.i' Reverted 'reports/aam/dgtlsubaudit/createtemp.i' Reverted 'reports/aam/dgtlsubaudit/valedittype.i' Reverted 'reports/aam/dgtlsubaudit/dgtlsubaudit.i' Reverted 'reports/aam/dgtlsubaudit/input.f' Reverted 'reports/aam/dgtlsubaudit/valedition.i' Reverted 'reports/aam/dgtlsubaudit/write.p' Reverted 'reports/aam/dgtlsubaudit/valdrawtype.i' Reverted 'reports/aam/dgtlsubaudit/guiprocs.p' Reverted 'reports/aam/dgtlsubaudit/dgtlsubaudit.p' Reverted 'reports/aam/dgtlsubaudit/valauditdate.i' Reverted 'reports/aam/dgtlsubaudit/guidgtlsubaudit.p' Reverted 'reports/aam/dgtlsubaudit/inp
Copy across repositories
Hi, I was given an assembly which comes from different repo to be used in my project. I added the assembly to my repo writing in comment field the source of origin. However, is there any other way to copy/link the assembly along with putting the information in the 'Copied from' field - as the 'Copied from' appears when I do the branch - instead being forced to put the comments about source of origin in the Comments field? Can I edit the 'Copied from' field manually? At this occasion I don't want to use the externals feature. Kamil
Re: Copy across repositories
Hello, On 07/07/14 18:01, Kamil Libich wrote: > I was given an assembly which comes from different repo to be used in > my project. I added the assembly to my repo writing in comment field > the source of origin. > > However, is there any other way to copy/link the assembly along with > putting the information in the 'Copied from' field - as the 'Copied > from' appears when I do the branch - instead being forced to put the > comments about source of origin in the Comments field? Can I edit the > 'Copied from' field manually? No. Cross-repository copies will appear as adds. The "Copied from" output is not an editable meta data field but the manifestation of the internal shallow copies only possible within the same fs. The vendor branches method may fit your use case. With kind regards, Andreas Stieger
