wc.db-journal files not being backed up by Time Machine
I have several SVN repositories on my local hard disk, a Mac running El Capitan 10.11.6. I back up my disk using Time Machine and then use diff in the Terminal to verify the backup. Since I upgraded to SVN 1.7.22 I've noticed that diff tells me none of my repositories' wc.db-journal files are being backed up. I haven't added them to the TM exclusions list, so this surprises me. Should I worry about this? Or is wc.db-journal a file that gets recreated if SVN doesn't find it? Googling doesn't turn up anything useful, nor does searching the list archives here. TIA
Re: Checkout through link ignores rev parameter
On Mon, Jan 23, 2017 at 7:54 PM, Dalton, Bill (GE Energy Connections) wrote: > We have projects which share some of the files in the subversion folders but > not all. So, those projects put their files into separate folders. One of > the pairs of folders contains the actual files. The other folder of the > pair has subversion links which point to the actual files in the other > folder. This strategy seems to work with only one very important exception. > When the folder with the links is checked out, the actual files always > return the HEAD version, ignoring the “rev=” parameter. > > > > Specifically, there are two folder in Subversion whose paths are > “trunk/firmware/cpu_fw/dia” and “trunk/firmware/cpu_fw_vx7/dia”. Most of > the files in the cpu_fw_vx7/dia folder (that is, all of the shared files) > are links which point to the corresponding file in the cpu_fw/dia folder. > If the cpu_fw_vx7/dia folder is updated with a “svn update -r 17905 > –non-interactive –force svnRepos/trunk/firmware/cpu_fw_vx7/dia” command, it > will always fetch the HEAD revision, instead of the 17905 revision. Hi Bill, There is no such thing as "Subversion links". I'm assuming you mean "externals" (more specifically "file externals", if I understand correctly). Anyway, I think what you're seeing is this bug (which is very old): https://issues.apache.org/jira/browse/SVN-2516 (--revision option is not forwarded to svn:externals references) The issue was last updated in 2015, with a reference to a mail thread on the dev-list, containing a design / specs discussion (which unfortunately seems to have stranded): http://svn.haxx.se/dev/archive-2015-08/0179.shtml -- Johan
Re: Checkout through link ignores rev parameter
What version of the Subversion client & server are you using? Eric On Mon, Jan 23, 2017 at 10:54 AM, Dalton, Bill (GE Energy Connections) < bill.dal...@ge.com> wrote: > We have projects which share some of the files in the subversion folders > but not all. So, those projects put their files into separate folders. > One of the pairs of folders contains the actual files. The other folder of > the pair has subversion links which point to the actual files in the other > folder. This strategy seems to work with only one very important > exception. When the folder with the links is checked out, the actual > files always return the HEAD version, ignoring the “rev=” parameter. > > > > Specifically, there are two folder in Subversion whose paths are > “trunk/firmware/cpu_fw/dia” and “trunk/firmware/cpu_fw_vx7/dia”. Most of > the files in the cpu_fw_vx7/dia folder (that is, all of the shared files) > are links which point to the corresponding file in the cpu_fw/dia folder. > If the cpu_fw_vx7/dia folder is updated with a “svn update -r 17905 > –non-interactive –force svnRepos/trunk/firmware/cpu_fw_vx7/dia” command, > it will always fetch the HEAD revision, instead of the 17905 revision. > > >
Svndumpfilter updating mergeinfo incorrectly?
Hello all I believe I discovered a potential bug in how svndumpfilter updates the mergeinfo property. I would like your feedback on whether this is indeed a bug or if I am misunderstanding something in a grand way. The problem is that in revision 10, the merginfo property of /trunk:4,6,9 is updated to /trunk:4,6,8-9 when a) we use the --drop-empty-revs --renumber-revs options b) drop revision 9 by delete the files added in revision 9. Looking at the svn code, my understanding is that this happens because a merge range of 9 is represented as a range of 8-9 internally. When the 9 is updated to 8 (after dropping revision 9) we end up with a range of 8-8 internally. Clearly this is meaningless so the code that prints the merge range adds one to the ending range. My theory is that the correct approach would be to drop the 9 from the mergeinfo thus getting /trunk:4,6 Is my above theory correct? I am attaching a mergetest.dump based on a small test repository I created to illustrate the problem. To command that drops revision 9 is shown below for your convenience. svndumpfilter exclude --drop-empty-revs --renumber-revs /trunk/file-e.txt /branches/trunkbranch/file-e.txt < mergetest.dump > problematic.dump I looked in Jira and I could not find a relevant bug hence this email. Looking forward to the views of the community. Thanks Doros mergetest.dump Description: Binary data
Re: svn congif
Hello Bashir, On Tue, Jan 24, 2017 at 3:23 PM, boshir sk wrote: > > Hello, > > Please tell me how to configurations Setup-Subversion-1.8.17 local computer > working on LAN connant all computer First and all, if you are new to Apache Subversion, you should read Version Control with Subversion book (SVNBook). SVNBook is the Bible of SVN and must-read for Subversion administrators and users. See SVNBook at http://svnbook.red-bean.com/. If you plan exposing your SVN repositories to users, you should deploy and configure a Subversion server. You could build and configure the server from scratch. However, there are several products that could help you with that. Use web search or check Apache Subversion Binary Packages page at http://subversion.apache.org/packages.html Feel free to ask if you have any specific questions. -- With best regards, Pavel Lyalyakin VisualSVN Team
svn congif
Hello, Please tell me how to configurations Setup-Subversion-1.8.17 local computer working on LAN connant all computer Thanks, bashir sk
Checkout through link ignores rev parameter
We have projects which share some of the files in the subversion folders but not all. So, those projects put their files into separate folders. One of the pairs of folders contains the actual files. The other folder of the pair has subversion links which point to the actual files in the other folder. This strategy seems to work with only one very important exception. When the folder with the links is checked out, the actual files always return the HEAD version, ignoring the "rev=" parameter. Specifically, there are two folder in Subversion whose paths are "trunk/firmware/cpu_fw/dia" and "trunk/firmware/cpu_fw_vx7/dia". Most of the files in the cpu_fw_vx7/dia folder (that is, all of the shared files) are links which point to the corresponding file in the cpu_fw/dia folder. If the cpu_fw_vx7/dia folder is updated with a "svn update -r 17905 -non-interactive -force svnRepos/trunk/firmware/cpu_fw_vx7/dia" command, it will always fetch the HEAD revision, instead of the 17905 revision.
