RE: Consultant
Why not go with a cloud based hosting provider? There are quite a few professional ones out there. I expect it would cost less to pay one of these providers than a single person dedicated to supporting you. http://www.svnhostingcomparison.com/ From: Matthias Kehder [mailto:mkeh...@modernanalytics.com] Sent: Tuesday, June 09, 2015 4:50 PM To: users@subversion.apache.org Subject: Consultant Hi All, Not sure this is the right place to post this, but I am looking for someone to setup and maintain a subversion repository for my company here in good-old San Diego. You can reach me at mkeh...@modernanalytics.commailto:mkeh...@modernanalytics.com. Kind regards, Matthias Kehder
RE: PVCS to SUBVERSION
We used this: http://www.polarion.com/products/svn/svn_importer.php it worked very well. From: G Suresh [mailto:sures...@hcl.com] Sent: Tuesday, March 03, 2015 7:36 AM To: users@subversion.apache.org Subject: RE: PVCS to SUBVERSION Hi, We want to migrate Pvcs to Subversion. Could you please provide the steps, how to migrate the pvcs to svn. It would be great full for us. Regards Suresh. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
RE: svn upgrade does nothing
I suggest you do a new, clean checkout. You can just copy the dirty files into
the new working copy.
From: Julio Andre Biason [mailto:jabia...@ucs.br]
Sent: Tuesday, October 21, 2014 12:11 PM
To: users@subversion.apache.org
Subject: svn upgrade does nothing
Hello,
I'm having a weird issue with subversion: Every command is interrupt with this:
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jabiason/{work}' is too old (format
10) to work with client version '1.8.10 (r1615264)' (expects format 31). You
need to upgrade the working copy first.
I run svn upgrade (even multiple times) but the problem still happens.
As a temporary solution, I checked the source out in a different directory, but
there is a little snag: For my reluctance in commiting mid change, there are
some files that are not part of the repo yet but I can't see them because svn
st is interrupted mid processing with the error above.
svn --version
svn, version 1.8.10 (r1615264)
compiled Aug 20 2014, 08:13:28 on x86_64-redhat-linux-gnu
(It is the default subversion packaged by Fedora, btw).
Enviado via UCSMail.
RE: Every Version of Every File in a Repository
You know, the files aren't really stored as files per say. Also, if using correct ACLs in your repository there is no way any of these files can be executed. I assume by scan you are talking about virus scanning. I would question the need to do this. Yea, I know... but still, many request come from a lack of understanding of a technology. From: jt.mil...@l-3com.com [mailto:jt.mil...@l-3com.com] Sent: Tuesday, October 07, 2014 4:03 PM To: users@subversion.apache.org Subject: Every Version of Every File in a Repository Is there a way to check out every version of a file in a repository? We just had a requirement levied to perform a scan of every file in a repository. The scan tool must have each file in a stand-alone format. Thus, I need a way to extract every version of every file within a repository. Aside from the brute-force method of checking out the entire repository starting at revision 1 , performing a scan, updating to the next revision, and repeating until I reach the head, I don't know of a way to do this. Thanks, JT Miller
RE: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 12:58 PM, Bob Archer bob.arc...@amsi.com wrote: -Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? If so, you can use ssh+svn protocol, essentially running svnserve on demand. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation. You don't need an svnserve daemon running for svn+ssh. It runs a temporary daemon, tied to that particular SSH session, owned by the same user who owns the SVN repo if it's configured correctly. Right, those were two separate suggestions. Use SSH+SVN or just run the svnserver daemon and use svn://
RE: Blocking root from SVN repository
-Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? If so, you can use ssh+svn protocol, essentially running svnserve on demand. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation.
RE: newbie cant import files into repo
Hi, I created a repo using svnadmin create in a dir called trunk (that's what your supposed to do, right?) The operation succeeded but the files that I want to version (c source which I should have versioned long ago.) I can't seem to add to the repo. When the code is ready for alpha release I plan to host it on source forge but until then It's just me working on the code and my online connection is intermittent so I decided to create my repo locally. I'm not subscribed so please include my email in your reply. Thanks, David You can create your repository in any folder you want. It doesn't have to be in a folder named trunk. Trunk is usually a folder that you create insider your repository. I assume you want to do this all locally. So, create your repository. md TempRepoRoot cd TempRepoRoot svnadmin create MyRepo Once you do that you want to do a check out. md Projects (probably in your user folder) cd Projects (probably in your user folder) Now do your checkout with the file protocol: svn co file:///c:/%HOMEPATH%/TempRepoRoot/MyRepo MyWorkingCopy Now you have checked out your repo you can create some folders: Cd MyWorkingCopy Svn mkdir trunk Svn mkdir branches Svn mkdir tags Then, check that in... Svn ci -m Initialize repo Now you probably want to checkout trunk, or perhaps switch to trunk. Up to you. Cd .. svn co file:///c:/%HOMEPATH%/TempRepoRoot/MyRepo/trunk ProjectTrunk Then, copy all your files into there. Do an svn add and Bob's your uncle.
RE: 10 seconds timeout before each operation involving network connection
I posted this already on the TortoiseSVN mailing list and it was suggested to report it to the Subversion Users mailing list: We are using TortoiseSVN (1.8.x) and the subversion command-line client (1.8.8) on Windows7 clients together with a VisualSVN (2.5.x) Server inside our company network. On some clients, there was a timeout of about ten seconds before each operation which involved contacting the server, e.g. commiting, updating, repo-browsing, etc. We analyzed this behavior using WireShark and SysInternals procmon. In the end, we found out that the problem exists only on clients with network adapters showing Unidentified Network such as virtual machine host adapters when no VM is running or network adapters with wrong IP settings. When all these adapters are set to disabled, the problem doesn't exist anymore and the transaction begins within a second. Adapters, either physical or virtual, with unplugged cables are no issue. As a workaround, we tried to set the priority of the network adapter connected to the company LAN to the highest value, but without any success. The problem also exists with the command-line client delivered with TortoiseSVN. Can someone reproduce this behavior? Interesting. We are seeing an initial delay when doing commits recently also using Tortoise. However, I'm 99% sure it started when I upgraded the server from 1.7.x to 1.8.x. So, I can't see this being a client side issue. However, I'd like to check. Where do you see Unidentified Network I did an ipconfig /all and don't see that term at all even on the VMWare adapters.
RE: Configure user name?
Does subversion provide a way for the user to configure his username, thus avoiding having to pass the --username flag everytime he has to commit something? Thanks Zé The credentials should be cached. If they are not being cached check in ~/.subversion/config, you probably have store-passwords = no. Change it to yes (or just comment it out because it defaults to yes), and the next time you give subversion your password it should save it.
Working copy blocking
We are all running the latest TortoiseSVN which is build with svn 1.8.8. Attempting to add files, I got this message (retrying it, the add worked) Command: Add Error: sqlite[S5]: database is locked Error: Additional errors: Error: sqlite[S5]: database is locked Error: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server. Completed!: This is on a Windows 7 system. The working copy is on the local drive. I'm thinking it is because perhaps we use both Tortoise and Ankhsvn? What can I look at?
RE: Working copy blocking
On 04/04/14 18:13, Bob Archer wrote: [TVSN + AnkhSVN on Win7] Error: sqlite[S5]: database is locked Error: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server. Check if either client has exclusive locking configured: https://subversion.apache.org/docs/release-notes/1.8.html#exclusiveloc king Andreas Can you remind me where the svn config file is on windows? Tortoise doesn't seem to want to open the file.
RE: How to do a partial merge from branch to trunk?
Hi I am working on a branch and I want to feed some (but not all) of my changes back into the trunk and then to continue work on the branch. Please will someone advise me of the correct way to handle this situation? Best regards David Generally the smallest unit you can merge is a single changeset. Check out the docs on merging and look for the Cherrypicking section.
RE: Created branches, tags, and trunk after the fact, MOSTLY works
Are you branching from a point prior to moving your project into the trunk directory? -Original Message- From: Kevin Ross [mailto:ke...@familyross.net] Sent: Monday, February 24, 2014 4:47 PM To: users@subversion.apache.org Subject: Created branches, tags, and trunk after the fact, MOSTLY works Hello, When the project repository was setup, we didn't include branches, tags, and trunk (oversight on our part). It wasn't until we decided we wanted to start branching that we realized this mistake. So in TortoiseSVN repo- browser, I created branches, tags, and trunk folders, and from the repo- browser, moved the existing folders into the trunk folder. I also then created a branch from a specific revision, and it created the branch for me. I've committed changes to the branch (and to the trunk) without problems. However, if I try to svn switch between trunk and a branch, I get no common ancestry error (which I can override with --ignore-ancestry), which leads me to believe that I didn't recreate the folder hierarchy correctly. Can anyone help? Thanks! -- Kevin
RE: Created branches, tags, and trunk after the fact, MOSTLY works
Ah, that's what I get for responding before reading the whole thread. Glad you figured it out. -Original Message- From: Kevin Ross [mailto:ke...@familyross.net] Sent: Monday, February 24, 2014 5:48 PM To: Bob Archer; users@subversion.apache.org Subject: Re: Created branches, tags, and trunk after the fact, MOSTLY works Yes, that was the problem. I figured it out a little while ago and posted my findings. Thanks for your help! -- Kevin On 2/24/2014 2:46 PM, Bob Archer wrote: Are you branching from a point prior to moving your project into the trunk directory? -Original Message- From: Kevin Ross [mailto:ke...@familyross.net] Sent: Monday, February 24, 2014 4:47 PM To: users@subversion.apache.org Subject: Created branches, tags, and trunk after the fact, MOSTLY works Hello, When the project repository was setup, we didn't include branches, tags, and trunk (oversight on our part). It wasn't until we decided we wanted to start branching that we realized this mistake. So in TortoiseSVN repo- browser, I created branches, tags, and trunk folders, and from the repo- browser, moved the existing folders into the trunk folder. I also then created a branch from a specific revision, and it created the branch for me. I've committed changes to the branch (and to the trunk) without problems. However, if I try to svn switch between trunk and a branch, I get no common ancestry error (which I can override with --ignore-ancestry), which leads me to believe that I didn't recreate the folder hierarchy correctly. Can anyone help? Thanks! -- Kevin
RE: svndumpfilter woes
Are you streaming to disk, then loading from disk? You might want to just directly pump the dump stream into the load. Just an idea. From: Ian Wiles [mailto:ian.alexander.wi...@googlemail.com] Sent: Friday, February 07, 2014 3:04 AM To: subversion_us...@googlegroups.com Cc: Ian Wiles; users@subversion.apache.org; m.scha...@codesys.com Subject: Re: svndumpfilter woes Hi Markus, Thanks. I ran verify and everything passed. which is good, so I assume it's recoverable somehow. I'm going to try a fresh dump and see if that helps. For now I've loaded the last few revisions which is enough for me to be getting on with until I figure out how to stop svndumpfilter ignoring me. Cheers, Ian On Friday, February 7, 2014 8:06:49 PM UTC+13, Markus Schaber wrote: Hi, Ian, I think that you should try to check / consider two scenarios: - Repository corruption: Maybe the existing repository contains Inconsistent data for some reason. You should try to check svnadmin verify on the repository, this will find most kinds of corruption. - Hardware failure: The data reading from the harddisk or your RAM may be broken, and occasionally flip some bits. This may be the case on the existing server, as well as on the destination machine. Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.sc...@codesys.comjavascript: | Web: codesys.comhttp://codesys.com | CODESYS store: store.codesys.comhttp://store.codesys.com CODESYS forum: forum.codesys.comhttp://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 Von: Ian Wiles [mailto:ian.alexa...@googlemail.comjavascript:] Gesendet: Freitag, 7. Februar 2014 06:29 An: subversi...@googlegroups.comjavascript: Cc: us...@subversion.apache.orgjavascript:; tscho...@am-soft.dejavascript: Betreff: Re: svndumpfilter woes On Thursday, February 6, 2014 10:42:24 PM UTC+13, Thorsten Schöning wrote: Guten Tag Ian Wiles, am Donnerstag, 6. Februar 2014 um 09:39 schrieben Sie: It's a problem since trying to load the dump in the new repo is failing on some binary files so I can't load the repo at all. If that's the only reason you want to get rid of the files in your dump, you may provide the error message and fix this error because SVN should be able to load even large binaries. svndumpfilter exclude --pattern *.ncb orignal_dmp.fil filtered_dmp.fil May this get translated to /*.ncb only and therefore doesn't get applied recursively? Maybe you need something like **/*.ncb. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow Hi Thorsten , thanks for the response. My main concern at the moment is just loading the dump file and the errors are preventing that. It would be good to filter out the binaries, but its not a priority just now. The error I get is a hash checksum failure, and only on binary files: * editing path : MyFile.ncb ...svnadmin: E200014: Checksum mismatch for '/MyFile.ncb': expected: ab27603550fc52585bd6e98c6d7d0b6c actual: f52642a0cc3186a7da837569fcde32a1 A re-dump didn't seem to help much. In fact I split up the dumps by revision in a bid to fix the problem, but then I got a failure earlier in the repository around revision 2xx. In fact whatever dump file I take seems to fail to load at some point due to a binary file checksum mismatch, which is pretty frustrating. Cheers, Ian
RE: svn upgrade fails with failed assertion
I'm trying to upgrade a very old svn repo but the command is failing. % svn upgrade . svn: /build/buildd/subversion- 1.7.5/subversion/libsvn_subr/dirent_uri.c:1518: uri_skip_ancestor: Assertion `svn_uri_is_canonical(parent_uri, ((void *)0))' failed. [1] 3298 abort svn upgrade . Can anyone tell me what I'm doing wrong? I don't know, but 1.7 is up to 1.7.14... 1.7.5 is pretty old. Also, have you tried to dump and load?
RE: Multiple SVN repos with single server?
I've been using Apache to proide HTTP access to several different SVN repository directories on a single server for about 10 years. I'm moving everything to a new server and I was considering using SVNSERVE in place of or in addition to Apache for access to the repositories. Sure... but I would question why you would want to do this. You are just making more work for yourself and I don't see any advantage to providing both protocols. If you are looking for simpler management/upgrades I highly recommend Subversion Edge. It's free and make things simple to setup and manage. Is it possible to server multiple SVN repositories.. Where I mean completely different SVN directories. not separate folders within a single SVN repo. using SVNSERVE on a single server? If so, how? Also, is there any issue with running both SVNSERVE and Apache to provide both SVN protocol and HTTP protocol access to the same SVN repos at the same time? Thanks in advance, Tom
RE: Multiple SVN repos with single server?
We switched from svn:// to http:// and didn't see any pref difference. Then again, I didn't benchmark it. That said, we don't do any path based authorization and that may be the difference. I prefer edge mostly for the inclusion of the management console, the WebView, and the push button updates. But to each his own. Yes, it is entirely possible to just point Edge to existing repos and have it server them. That said, the answer to your question is yes, you can have mod_dav_svn and svnserver both serving the same repos. For svnserve to serve multiple, afaik, they need to all be rooted at the same location and you use the -d switch to specify that root location. -Original Message- From: Tom Malia [mailto:tomma...@ttdsinc.com] Sent: Friday, February 07, 2014 4:18 PM To: Bob Archer; users@subversion.apache.org Subject: RE: Multiple SVN repos with single server? I'm the first to admit I'm no expert... so I would not be surprised or offended to find I was asking for something really stupic. My logic for supporting both protocols is, my understanding is that SVN protocol can be substantially faster and I was planning to use this both as the preferred protocol for dedicated SVN Clients and for maintenance processes like SVNSYNC and SVNRDUMP. While, having access to the repos via HTTP give me more universal access for myself and my clients when we just need to read files potentially from locations that don't have any SVN client installed and/or which are blocking access to locations through anything other than HTTP protocols. When I looked at Subversion edge and played with it a little it looked really easy for setting up a completely new subversion server environment with new repositories. It wasn't immediately obvious to me how I would/could attach edge to existing repositories. I didn't really like installing a completely separate Subversion, Apache stack when I already have an apache and tomcat server running and figured I could just use what I had already. Again my lack of experience and knowledge here are probably painfully obvious to everyone but me on these subjects ignorance is NOT always bliss. -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Friday, February 07, 2014 3:11 PM To: Tom Malia; users@subversion.apache.org Subject: RE: Multiple SVN repos with single server? I've been using Apache to proide HTTP access to several different SVN repository directories on a single server for about 10 years. I'm moving everything to a new server and I was considering using SVNSERVE in place of or in addition to Apache for access to the repositories. Sure... but I would question why you would want to do this. You are just making more work for yourself and I don't see any advantage to providing both protocols. If you are looking for simpler management/upgrades I highly recommend Subversion Edge. It's free and make things simple to setup and manage. Is it possible to server multiple SVN repositories.. Where I mean completely different SVN directories. not separate folders within a single SVN repo. using SVNSERVE on a single server? If so, how? Also, is there any issue with running both SVNSERVE and Apache to provide both SVN protocol and HTTP protocol access to the same SVN repos at the same time? Thanks in advance, Tom
RE: Showing unmerged revisions within a range
I created a branch (4.0.x) from trunk. Work progressed on trunk and was
selectively merged down to the 4.0.x branch.
The intent was to do our next release off this branch and then kill it.
Subsequent releases would come from the trunk (or branches thereof).
Unfortunately plans changed, and we needed to clone the 4.0.x branch to
produce a 4.0.2 branch. Subsequent changes were made on the trunk and
merged individually to each branch.
We've since released 4.0.2, and so I want to kill the 4.0.2 branch.
Before doing that, I want to ensure that all changes which were merged from
the trunk to the 4.0.2 branch also made it to the 4.0.x branch.
I tried the following:
% svn log --stop-on-copy ${Repository Root}/branches/4.0.2 [ ...snip... ]
r202859 | kyle | 2014-01-29 11:50:48 -0800 (Wed, 29 Jan 2014) | 2 lines
% svn info
Path: .
URL: ${Repository Root}/branches/4.0.x
% svn mergeinfo -r202859:HEAD --show-revs=eligible $Repository
Root}/branches/4.0.2 .
svn: E195008: Revision range is not allowed
Why does mergeinfo say revision range is not allowed when svn help
mergeinfo lists --revision under Valid options?
The help says:
(some commands also take ARG1:ARG2 range)
Did you not get what you wanted without specifying a range?
Hmm... I just tried it and didn't get that error:
svn mergeinfo -r6000:HEAD --show-revs eligible
http://myserver/svn/manage/MyAppRootName/v7.5.4
r60148
r60155
r60156
r60157
r60158
I'm using 1.8.4.
BOb
RE: ignore property not ignoring...
From: Edward Ned Harvey (svn4) [mailto:s...@nedharvey.com] So I have to just duplicate the svn:ignore and svn:global-ignores properties everywhere that anything needs to be ignored. Sorry, clarification: In tortoise, I check the properties of some directory, and it shows svn:ignore bin obj and some other stuff. But it's gray. So I assume it's inherited from a parent, and effective at this level, and then it turns out, not to be effective. I go to command prompt, and I see in fact, those properties are set on the root directory, and *not* on the subdirectory. I don't know why it's displaying grayed out, but if I explicitly set that property on that directory, then it works. So I guess this is mostly a usage issue. I could go talk to the tortoise folks about why it's showing gray, when it's not effective... And I could complain that when you click on add to ignores the default is now to use global- ignores rather than ignore... But it's not worth it. In 1.8 all properties are automatically inherited. Tortoise SVN shows those as gray so you know they were inherited. That said, the 1.8 client only acts on specific properties that were inherited. svn:global-ignores and svn:auto-props. I think there was some talk on the TSVN list to have a check box to show inherited. But, not sure if that will happen. Thanks for your help. I think it's under control now. BOb
RE: How to change the svn password by the user?
Hi, I am from PTC Software, Pune. I wanted a normal user(not admin) to change his credentials in SVN. Can you please help with this? Thanks, -Narayana Reddy. I would suggest using Subversion Edge by Collabnet. It is free, and bundles svn, apache and a web based management tool. Users can log into the web portal and change their passwords. I'm not sure if there is a way to force password changes... for that I suggest using windows domain accounts or some NTLM server. BOb
RE: Repository Structure Question
I'm part of a small development team (currently 4). We have two applications used in-house that consist of about 1900 source files. The two applications share about 1880 of the files in common, and there are only about 20 different between them. For a lot of complicated reasons I won't go into here, we can't split the common files into a shared-library sort of project. Most of our development goes on in application 'A'. Currently we then transferred over to the other application 'B' development machine manually and build/test that one. I was thinking of having all the 'A' files be in the main /application/trunk tree of the repository and then somehow have just the 20 or so files unique to 'B' in some sort of /application/branches/Bapp directory tree. This means I'd have to 'switch' those 20 files, (one time only right?), on the B- development machine so it would be a mix of mostly /trunk and just those few files under /branches/Bapp. This would mean that once changes made on the 'A' system are committed, we could just go to the 'B' machine, do an update, and build. If a change happened to be on one of the 20 files, we would have to 'merge' that change from /trunk over into the /branches/Bapp tree, right?? I think we can live with that. Does this sound like it would work, or is there a better way (short of splitting 1880 files off into some other project)?? Currently the team hasn't used any form of version control on these applications because 'it would be too hard...' I desperately want to get it/them under subversion without making two complete projects. I know subversion won't 'share' files between projects and I understand about that. But I just need a way to deal with these 20 out of 1900 files. (may even be less than that when we start actually digging into it) There's a couple of ways to do this. Externals might help it really depends on if those 20 files are all isolated in a single folder for example. Also, you don't need spate machines you can have separate working copies on the same machine. It sounds like you are saying those files are not completely different but there are differences from one build to the next. Also, it sounds like a VERY small portion of the overall app... due to this... I would suggest that you use Build/compiler defines/switches with compiler directives (most languages have them) with branching logic. For example in C# you could do: #if APPA // changes or branching or whatever that is needed for app A #endif Then, your build scripts can define APPA or APPB. This is pretty common way to include or exclude debug code... but doing it for different apps or distributions of apps is another common use. BOb
RE: help with svn:ignore
I am using Subversion 1.6.11-10 on Red Hat Enterprise 5.8. The repository is strictly for RANCID and I recently renamed several files in my repository with the svn move command. After making these changes I found that I can no longer see the file history for the renamed files in my repository viewer, OpenGrok. I have checked out an updated copy of the repository and cleared the OpenGrok caches but still cannot see historical revisions. I executed an svn log for the repo with the following results. r2044 | rancid | 2013-12-11 17:38:10 + (Wed, 11 Dec 2013) | 1 line new router r2043 | rancid | 2013-12-10 22:31:13 + (Tue, 10 Dec 2013) | 1 line updates r2042 | rancid | 2013-12-10 20:56:41 + (Tue, 10 Dec 2013) | 1 line updates r2041 | rancid | 2013-12-10 20:34:13 + (Tue, 10 Dec 2013) | 1 line set svn:ignores r3 | rancid | 2013-12-10 19:04:29 + (Tue, 10 Dec 2013) | 1 line new Newer revisions show updates or new router (new file) and there is history for all revisions past r2041. I executed svn propdel svn:ignore --revprop -r 2041 file:///opt/rancid/archives/SVN/CISCO/ and received a message of property 'svn:ignore' deleted from repository revision 2041. I then update my RANCID working copy on the server with svn update and check out the changes for OpenGrok but I still cannot see historical changes. The changes are in the repository because I can execute svn cat file:///opt/rancid/archives/SVN/CISCO/configs/router1 -r1663 to see the historical file. Can someone help me find a way to remove the svn:ignore that has been set at revision 2041? You can't remove versioned properties. Changes to those properties are part of the history of the file/path just like the changes made to the file. It is not a revprop. That said, svn ingnore doesn't affect stuff that is in the repository already. So, I don't think that is your problem. Also, the property affects when stuff is added. When you did the move, did you commit both the ADD and the DELETE? You can verify by looking at the commit info. Does OpenGrock perhaps automatically include a --stop-on-copy for the log command? BOb
RE: Update-Only Checkout Enhancement
Yes, I understand the export function. I want functionality for release management into test and production environments. For these environments I have a few requirements: Files in these environments will NEVER be edited For new releases I will need to perform an update to revision, which will add, update and delete needed files I want as small of a .svn directory as possible Why? Disk is cheap. Much cheaper than the time it would take to modify svn to work the way you are requesting. Heck, I just bought a 1TB SSD for ~$500. The spinning version was about $120. I would recommend you write a script that does an export rather than using the update feature. Although, this would probably mean the task would take longer, since you don't have the benefit of the .svn pristines to know what changed files need to be requested from the server. But, it sounds like you care more about disk space than network traffic and/or time. Of course, that is your decision to make. I'm fairly certain that this functionality is currently not present, but I think there are many installations where this would be valuable. I'd like to create an enhancement request, but according to the website it was recommended that I post to this mailing list first. -Original Message- From: Cooke, Mark [mailto:mark.co...@siemens.com] Sent: Wednesday, December 11, 2013 1:44 AM To: Mark Kneisler; users@subversion.apache.org Subject: RE: Update-Only Checkout Enhancement -Original Message- From: Mark Kneisler [mailto:mark.kneis...@tceq.texas.gov] Sent: 11 December 2013 01:45 I have several environments where I'd like to use a SVN checkout, but where I'd never ever want to make changes to the files or perform a commit. For these environments, I'd only want to perform an update or an update to revision. I'm hoping that this type of checkout would require far less space for the .svn directory. AFAIK there is no such option for a checkout, however, you can get the source without the .svn folder using the export command:- http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.export.html ...you can specify the revision etc. Note, however, that it will not remove unwanted files like an update can. ~ mark c P.s. I think Thorsten just beat me to it...
RE: Update-Only Checkout Enhancement
On 11.12.2013 17:21, Mark Kneisler wrote: I think making the pristine files optional would work for me. Here’s an idea. Instead of having pristine copies of all files, how about adding to the pristine directory only when a file is changed? You know, that's a great idea! I wonder why we never thought of it ourselves? :) Wouldn't that mean that you need to have some daemon service (or file watcher or something) running to determine if a file is modified? Also, it would mean you would need a constant connection to the server to use a subversion working copy. BOb
RE: Update-Only Checkout Enhancement
On 11.12.2013 20:19, Bob Archer wrote: On 11.12.2013 17:21, Mark Kneisler wrote: I think making the pristine files optional would work for me. Here’s an idea. Instead of having pristine copies of all files, how about adding to the pristine directory only when a file is changed? You know, that's a great idea! I wonder why we never thought of it ourselves? :) Wouldn't that mean that you need to have some daemon service (or file watcher or something) running to determine if a file is modified? Yes. Also, it would mean you would need a constant connection to the server to use a subversion working copy. Not necessarily; we don't need a pristine copy to check if a file is modified, or if 's out of date WRT the repository. But the former problem (requiring a daemon) is already a non-starter. Right, but if a file is modified you would need to contact the repository to get the pristine because you are going to get an event after the file is modified. There may be some transactional file systems that allow you to get an event before the modification is committed to the file system so you can access the original copy, but I think they are few and far between. (So I guess your original response of great idea was sarcastic and I didn't see it.) BOb
RE: Why does `svnversion -c` give me a range?
Hi Folks, I would like to include the svn revision number in my project's version info but I am confused by the results of svnversion. I want the version number of a tagged tree to always be the same (i.e. the last commit to the tag) but if the tag is to be rebuilt using a fresh checkout some time later `svnversion` seems to report the HEAD revision. So I looked at `svnversion -c` but this always seems to give me a range e.g. `2:1476`, even directly after an update. I have read the red book but it is quite vague about the -c option. Why is `-c` always giving me a range? Many thanks, ~ mark c If you are on windows you can use SubWCRev which is distributed with tortoiseSVN. It is designed to do what you want. http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html BOb
RE: Hardware requirements for windows subversion
Hi Edward, Thank you for your response. I have a .net site the file size is 2 GB. There are only 2 developers working on this project remotely. Do I need windows server or windows 7? What kind of hardware, RAM, diskspace do I need? Do I still need Apache server? Where can i get Subversion installation from? Do I need to install visualSVN or serveSVN? You wrote that configuring the encryption takes a lot more complexity, is there any step-by-step instructions on that? What do you mean by serial processing? I don't have more than one cpu available. Your help is greatly appreciated, Ram I would recommend a Server OS, Win 2008R2 or 2012. Also, a server level hardware... it doesn't need much... it could be a VM as well. But, treat it as a server, in a data closet, with daily backups and a powerback up etc. You don't need Apache, but I would recommend it. svn:// is fine. If you are going to host it yourself I would recommend Subversion Edge from collabnet. It is an all inclusive single install. It gives you a nice simple Web based management console as well. It will do upgates for you, timed backups, even backup to the cloud if you want. Encryption means using https:// it really isn't much more than putting a certificate on yours server. Easy for some, hard for others. However, with only 2 devs, you may want to look for a hoster online. Many places have free svn hosting for small groups. This way, they take care of the hard ware sizing and stuff. However, you would probably want to dump every now and then and store the dump file in a few places just in case. BOb
RE: Branch/switch/merge question
I've read the visual guide, the subversion book, I've used subversion for years, but never really collaborated much with other people on actual software source code the way it's intended to be used, until recently. So it's only recently that I'm making use of branch/merge, and I'd like to get the advice of you more experienced svn users, about my usage pattern. In particular, I branch (and switch) from /trunk to /branches/eharvey. I then make a few commits. I switch back to /trunk, and merge from the branch. I commit to trunk. (I'm always at a loss for comment, because I'm just committing things that have already been commented. But that's a side note.) I then switch back to /branches/eharvey, and merge from /trunk. So here's my question: Even if I'm the only person who committed anything... I was fully committed on /branches/eharvey, I then became fully committed on /trunk, and when I merge back into /branches/eharvey, suddenly I'm not fully committed. My latest status (check for modifications) shows the child subfolder as modified, and when I diff it, it's the svn:mergeinfo property that's different. It shows that I merged /trunk into /branches/eharvey, even though there were no changes from trunk to merge in. Are you using svn 1.8? If not, are you doing reintegration merge when merging your branch back in to the trunk? So, most importantly, am I using svn branch/switch/merge in the way that it's intended to be used? Is this the normal, expected, and desired behavior, and I should just get used to it? Should my usage pattern be different somehow? Generally, there isn't a reason to branch as a matter of course. It's not wrong per say... but I'd rather see all the work just done in trunk. Branches would be used for larger features that multiple people might collaborate on, or take longer than a day or so. Although, having each developer work only on a branch does facilitate code reviews. You do your work on a branch, someone reviews it, once ok'ed it gets merged to branch. Also, I suggest people avoid using switch. It is too easy to forget which svn path you are currently pointing to and commit something to the wrong path. Also, svn switch doesn't handle non-versioned stuff as well as say GIT does. I'd much rather see our devs check out trunk and branch to separate local working copies. BOb
RE: Looking into using Subversion
It seems pretty dangerous to me to just push dev changes to production. I suggest you have a build server, the watches for commits, runs unit tests and then deploys to staging. Once staging is tested you can push to production. But, yea, each dev should have their own working environment. It cause much less conflict and problems. BOb From: vanderwalt.dev...@columbus.co.za [mailto:vanderwalt.dev...@columbus.co.za] Sent: Monday, November 18, 2013 8:09 AM To: Nico Kadel-Garcia Cc: Subversion Subject: Re: Looking into using Subversion Thank for your response Nico. We what to debug from our development server. Not sure if there maybe is away to develop on the local PC, and check in the file into the repository (which will be on the Linux Server) which will copy it to the Tomcat's publish folder on the server? From:Nico Kadel-Garcia nka...@gmail.commailto:nka...@gmail.com To: vanderwalt.dev...@columbus.co.zamailto:vanderwalt.dev...@columbus.co.za Cc:Subversion users@subversion.apache.orgmailto:users@subversion.apache.org Date:2013/11/18 02:11 PM Subject:Re: Looking into using Subversion They can, in theory, but it's awkward. Two people editing the same file, at the same time are really likely to run into conflicts or accidentally mix their changes into the same commit. So I don't recommend it. Why can't they work on their own copies, on their own Tomcat servers, with tuned local Tomcat configs, and merge their changes in their own branches to a single master that is what lives on the website? On Mon, Nov 18, 2013 at 4:09 AM, vanderwalt.dev...@columbus.co.zamailto:vanderwalt.dev...@columbus.co.za wrote: Hi All I have been exploring the Subversion web site, also check out the High-Speed Tutorial. But stilling trying to work out if Subversion will be useful for us. We are developing a PHP Website hosted on our own Linux Server (a development server). We are also using Tomcat to host our website, and handle our Java Web Services for the website. The Developers are using Windows PC to develop, currently using, NetBeans for PHP development. And Eclipse for the Java Web services. The question is, can all the developers, work with the same working copy, which will be on the Linux server? Enjoy Devlyn This e-mail is subject to the Columbus Stainless [Pty] Ltd Email Legal Notices available at: http://www.columbus.co.za/EmailLegalNotice.htm. This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal This e-mail is subject to the Columbus Stainless [Pty] Ltd Email Legal Notices available at: http://www.columbus.co.za/EmailLegalNotice.htm. This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal
RE: Migrating ClearCase data to Subversion
Did you try this tool. It is what I used to migrate from PVCS. http://www.polarion.com/products/svn/svn_importer.php BOb From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Friday, November 15, 2013 5:47 PM To: users@subversion.apache.org Subject: Migrating ClearCase data to Subversion Hi, I could not find a tool or an automated way to migrate ClearCase vobs to SVN repositories. I guess there is not any perfect tool to do this. I don't think I can use timestamp to build revisions, like for migration cvs to svn. On the other hand, the real need is to migrate main to trunk, to migrate the other branches, probably just for the interesting file/directory versions - the labelelled ones. I have to migrate the ClearCase labels to SVN tags. I guess it is not possible to migrate the merge history. Could you help, please ? Olivier
RE: How to determine subversion repository format
I am getting this svn client message:
The working copy at repository
is too old (format 29) to work with client version '1.8.4 (r1534716)' (expects
format 31). You need to upgrade the working copy first.
I am interested in knowing where format 29 is stored. My searches have
lead me to repository/.svn/{entries,format} which both contain a single
line with the value of 14 and .svn/wc.db which when dumped with sqlite3
format 29 does not stand out to me.
Can someone point me to some documentation which explains where the
repository format information is stored for various version of subversion.
I know in this case that I my repository was last updated by subversion 1.7.x
but nonetheless I would like to know how to get the existing repository
format info without upgrading or installing older versions of subversion until
one works with an unknown repository format.
Regards,
Bradley Giesbrecht (pixilla)
I'm pretty sure this message is talking about the WORKING COPY version, not the
repository version. Format 29 is probably the working copy format for 1.7.x.
BOb
RE: not able to access repository form remote server
I installed win32svn in remote server which i can acees directly. I am trying to create subversion repository mirror in this remote server using svnsync through command line and the actual repo is located in different remote server.I am able to access this repo(from diff server) from SVNSLIK, but not able to connect subversion of windows compatible (win32svn) command used: svnsync init file:///repository htp://repoURL/trunk/repoName --source- username AAA --source-password PWD (then) Authentication realm: XXX Username: AAA Password: PWD Again asked username and password, even i entered correct authentication info, thrown error. Error: svnsync:E215004:Unable to connect to a repository at URL htp://repoURL/trunk/repoName plz help me on this. Is htp a typo in your email? You are using http:// when you are actually doing this? Also, is there a reason you aren't specifying --sync-username and --sync-password on your command line? Finally, I think your doing it backwards. The svnsync help shows: svnsync initialize DEST_URL SOURCE_URL Wouldn't file:///repository be your source, so your command line should be: svnsync init http://repoURL/trunk/repoName file:///repository --sync-username AAA --sync-password PWD ...since you are using file:/// protocol for your source. Also, did you heed this in the help? The destination URL must point to the root of a repository which has been configured to allow revision property changes. BOb
RE: Windows file:/// URL format for svnsync
Good point… our just use svnrdump to dump the repo… then you can take that
file, load it into a repo on another machine and then sync that to google.
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Wednesday, October 30, 2013 7:02 PM
To: 'David Goldsmith'
Cc: users@subversion.apache.org
Subject: RE: Windows file:/// URL format for svnsync
‘svn info WORKINGCOPY’ will tell you the url in the repository and the
repository root.
Assuming that you have access to the entire repository you probably want to
sync from the repository root to an empty repository to have a local backup.
(Look in http://svnbook.red-bean.com for details on how to setup the right
hooks, etc)
And with a bit less time pressure you can then sync that to google code.
Bert
From: David Goldsmith [mailto:eulergaussriem...@gmail.com]
Sent: woensdag 30 oktober 2013 22:59
Cc: users@subversion.apache.org
Subject: Re: Windows file:/// URL format for svnsync
Hi, Ben, and thanks for your reply. Unfortunately, I think that was the first
(or perhaps the second) thing I tried, to no avail (also unfortunately, I'm
away from my work computer for the rest of the day so I can't check my command
history or the error message it generated).
As I think about my sitch, I realize that the folder I thought was the root of
the repository probably isn't, because it's the root of the directory tree in
which reside all the files that I edit day-to-day, and that's supposed to be a
working copy, not the repository itself, correct? Assuming that's correct, my
ultimate goal is to relocate my project, with history, to a new, empty Google
code project (already created and reset)--how should I proceed: should I
continue to try to svnsync my new Google project to my existing repository (to
which I'll never again have access after tomorrow), and if so, how do I find my
repository from knowing where a working copy is ('cause, clearly, I've
forgotten)? Or should I just upload my working copy from its root, and then
check that out to any place else I want to be able to work on it--would such an
upload include the history, and would Google Code recognize it? Please
advise/help!
Thanks,
DG
YOU!...are Big Datahttp://en.wikipedia.org/wiki/Big_data.
On Wed, Oct 30, 2013 at 1:29 PM, Ben Reser
b...@reser.orgmailto:b...@reser.org wrote:
On 10/30/13 1:08 PM, David Goldsmith wrote:
Hi! I can't seem to get the formatting for my source repository name--which
is
a Windows directory--correct for svnsync: I've tried forward slashes and
backslashes, quotes and no quotes, relative path and absolute path--nada. My
repository, in Windows syntax, is C:\MWDM--how do I specify this as part of
the
source argument to svnsync? Thanks,
file:///C:/MWDMfile:///C:\MWDM
Note that there are 3 forward slashes before the path because you want a blank
host entry.
http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls
RE: Windows file:/// URL format for svnsync
Not sure how we got off list. But, I just used svnsync to move a repo to google code.. it was pretty easy. Just follow the instructions on their wiki page: How do I import an existing Subversion repository? To upload the history of an existing Subversion repository, use the svnsync tool that ships with Subversion 1.4 or later. Run svnsync help to read more about this tool. Note that your Google Code repository must be reset to revision 0https://code.google.com/p/support/source/detail?r=0 for this to work. Your project's Source tab will display instructions on how to reset the repository yourself. (Note: you must be a project owner to reset your own repository, and also to push code up with svnsync.) Here's a sample transcript that demonstrates how you can push history from an existing repository (located at file:///my/repos) to your repository on Google Code: $ svnsync init --username YOURUSERNAME https://YOURPROJECT.googlecode.com/svn file:///path/to/localrepos Copied properties for revision 0. $ svnsync sync --username YOURUSERNAME https://YOURPROJECT.googlecode.com/svn Committed revision 1. Copied properties for revision 1. Committed revision 2. Copied properties for revision 2. [...] When prompted for your password, use your googlecode.com password, which can be found on the settings tabhttp://code.google.com/hosting/settings of your profile page. Running svnsync on a large repository will take a significant amount of time. If you are disconnected during the process, you may see the error message svnsync: Couldn't get lock on destination repos after 10 attempts. If this happens, you can remove the lock yourself; see the Locks section of svnsync.txthttp://svn.collab.net/repos/svn/trunk/notes/svnsync.txt. BOb From: David Goldsmith [mailto:eulergaussriem...@gmail.com] Sent: Thursday, October 31, 2013 3:25 PM To: Bob Archer Subject: Re: Windows file:/// URL format for svnsync They used to have restrictions--for security--on what kind of executable code you could upload, but I think that was (is?) just for Google docs; AFA Google Code is concerned, seeing as how it's intended as an open source code hub, they allow just about anything (at least, anything text-based)--if there are restrictions, they don't feature them prominently, so I'm not aware of them. YOU!...are Big Datahttp://en.wikipedia.org/wiki/Big_data. On Thu, Oct 31, 2013 at 11:23 AM, Bob Archer bob.arc...@amsi.commailto:bob.arc...@amsi.com wrote: I’ve never used google reports. Do they let you upload and import a dump file? From: David Goldsmith [mailto:eulergaussriem...@gmail.commailto:eulergaussriem...@gmail.com] Sent: Thursday, October 31, 2013 2:05 PM To: Bob Archer Subject: Re: Windows file:///file:///\\ URL format for svnsync Why wouldn't I just upload it to Google? I guess what I'm missing is: how does SVN recognize history? By path and filename? So, if I preserve that, shouldn't that be enough to preserve the history? Thanks again! DG YOU!...are Big Datahttp://en.wikipedia.org/wiki/Big_data. On Thu, Oct 31, 2013 at 6:49 AM, Bob Archer bob.arc...@amsi.commailto:bob.arc...@amsi.com wrote: Good point… our just use svnrdump to dump the repo… then you can take that file, load it into a repo on another machine and then sync that to google. From: Bert Huijben [mailto:b...@qqmail.nlmailto:b...@qqmail.nl] Sent: Wednesday, October 30, 2013 7:02 PM To: 'David Goldsmith' Cc: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: Windows file:/// URL format for svnsync ‘svn info WORKINGCOPY’ will tell you the url in the repository and the repository root. Assuming that you have access to the entire repository you probably want to sync from the repository root to an empty repository to have a local backup. (Look in http://svnbook.red-bean.com for details on how to setup the right hooks, etc) And with a bit less time pressure you can then sync that to google code. Bert From: David Goldsmith [mailto:eulergaussriem...@gmail.commailto:eulergaussriem...@gmail.com] Sent: woensdag 30 oktober 2013 22:59 Cc: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: Re: Windows file:/// URL format for svnsync Hi, Ben, and thanks for your reply. Unfortunately, I think that was the first (or perhaps the second) thing I tried, to no avail (also unfortunately, I'm away from my work computer for the rest of the day so I can't check my command history or the error message it generated). As I think about my sitch, I realize that the folder I thought was the root of the repository probably isn't, because it's the root of the directory tree in which reside all the files that I edit day-to-day, and that's supposed to be a working copy, not the repository itself, correct? Assuming that's correct, my ultimate goal is to relocate my project, with history, to a new, empty Google code project (already created and reset)--how should I proceed: should
RE: Windows file:/// URL format for svnsync
Are you sure you are specifying a REPOSITORY and not a working copy??? BOb From: David Goldsmith [mailto:eulergaussriem...@gmail.com] Sent: Thursday, October 31, 2013 4:17 PM To: Bob Archer Cc: users@subversion.apache.org Subject: Re: Windows file:/// URL format for svnsync OK, now we're going in circles: what you cut and paste is what I've been trying, over and over again, to no avail (as I said in my OP, it didn't like the way I'm specifying my source folder.) I'm sure there's some subtlety that--as a user, not an admin--I'm missing, that those overly-simplified instructions aren't including, but I can't seem to communicate what it is. I'll try posting a transcript of my efforts. DG YOU!...are Big Datahttp://en.wikipedia.org/wiki/Big_data. On Thu, Oct 31, 2013 at 1:08 PM, Bob Archer bob.arc...@amsi.commailto:bob.arc...@amsi.com wrote: Not sure how we got off list. But, I just used svnsync to move a repo to google code.. it was pretty easy. Just follow the instructions on their wiki page: How do I import an existing Subversion repository? To upload the history of an existing Subversion repository, use the svnsync tool that ships with Subversion 1.4 or later. Run svnsync help to read more about this tool. Note that your Google Code repository must be reset to revision 0https://code.google.com/p/support/source/detail?r=0 for this to work. Your project's Source tab will display instructions on how to reset the repository yourself. (Note: you must be a project owner to reset your own repository, and also to push code up with svnsync.) Here's a sample transcript that demonstrates how you can push history from an existing repository (located at file:///my/reposfile:///\\my\repos) to your repository on Google Code: $ svnsync init --username YOURUSERNAME https://YOURPROJECT.googlecode.com/svnhttp://YOURPROJECT.googlecode.com/svn file:///path/to/localreposfile:///\\path\to\localrepos Copied properties for revision 0. $ svnsync sync --username YOURUSERNAME https://YOURPROJECT.googlecode.com/svnhttp://YOURPROJECT.googlecode.com/svn Committed revision 1. Copied properties for revision 1. Committed revision 2. Copied properties for revision 2. [...] When prompted for your password, use your googlecode.comhttp://googlecode.com password, which can be found on the settings tabhttp://code.google.com/hosting/settings of your profile page. Running svnsync on a large repository will take a significant amount of time. If you are disconnected during the process, you may see the error message svnsync: Couldn't get lock on destination repos after 10 attempts. If this happens, you can remove the lock yourself; see the Locks section of svnsync.txthttp://svn.collab.net/repos/svn/trunk/notes/svnsync.txt. BOb From: David Goldsmith [mailto:eulergaussriem...@gmail.commailto:eulergaussriem...@gmail.com] Sent: Thursday, October 31, 2013 3:25 PM To: Bob Archer Subject: Re: Windows file:///file:///\\ URL format for svnsync They used to have restrictions--for security--on what kind of executable code you could upload, but I think that was (is?) just for Google docs; AFA Google Code is concerned, seeing as how it's intended as an open source code hub, they allow just about anything (at least, anything text-based)--if there are restrictions, they don't feature them prominently, so I'm not aware of them. YOU!...are Big Datahttp://en.wikipedia.org/wiki/Big_data. On Thu, Oct 31, 2013 at 11:23 AM, Bob Archer bob.arc...@amsi.commailto:bob.arc...@amsi.com wrote: I’ve never used google reports. Do they let you upload and import a dump file? From: David Goldsmith [mailto:eulergaussriem...@gmail.commailto:eulergaussriem...@gmail.com] Sent: Thursday, October 31, 2013 2:05 PM To: Bob Archer Subject: Re: Windows file:///file:///\\ URL format for svnsync Why wouldn't I just upload it to Google? I guess what I'm missing is: how does SVN recognize history? By path and filename? So, if I preserve that, shouldn't that be enough to preserve the history? Thanks again! DG YOU!...are Big Datahttp://en.wikipedia.org/wiki/Big_data. On Thu, Oct 31, 2013 at 6:49 AM, Bob Archer bob.arc...@amsi.commailto:bob.arc...@amsi.com wrote: Good point… our just use svnrdump to dump the repo… then you can take that file, load it into a repo on another machine and then sync that to google. From: Bert Huijben [mailto:b...@qqmail.nlmailto:b...@qqmail.nl] Sent: Wednesday, October 30, 2013 7:02 PM To: 'David Goldsmith' Cc: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: Windows file:/// URL format for svnsync ‘svn info WORKINGCOPY’ will tell you the url in the repository and the repository root. Assuming that you have access to the entire repository you probably want to sync from the repository root to an empty repository to have a local backup. (Look in http://svnbook.red-bean.com for details on how to setup the right hooks, etc) And with a bit less time pressure you can
RE: Access Problem with Subversion
Hi all! I have a urgent problem with our subversion. I need to do a dump file, but I always get the answer, that I do not have access! But my user is administrator... Can you please help me? I really need this export! At this point, it simply a file access issue. This really has nothing to do with subversion. If you have access to run the exe and write access to the target directory then you should be good. However, I think you need to specify the dump file name... svnadmin dump path_to_repo e:\backup\reponame.dump Not sure if that is the issue. BOb
RE: svn mergeinfo and svn merge - questions
Hi All We are using 1.6 SVN. We like to svn merge from our branch A to trunk. We have been diligent in svn merge from trunk to A. These svn merges from trunk to branch A also include --record-only merges too, in addition to regular merges. Development on branch A has stopped. Now we like to merge branch A to trunk using --reintegrate option. But we dont know what to expect if using this option fails on us. 1) Suppose svn merge --reintegrate fails on us on a working copy that has all the mergeinfo list information. Could we perform a clean co of branch A into another working copy and then perform svn merge --reintegrate to trunk there ? Will we get more conflicts simply because the new working copy doesnt have the mergeinfo list like the first working copy of branch A ? Will this plan B work ? I'm not sure I follow. To reintegrate a branch into a trunk your merge target (the working copy) is the trunk. Having a branch checked out doesn't change this. 2) How do we resolve conflicts during svn merge --reintegrate process ? Would you share the steps for us to make the merge go smoothly ? It depends on the conflict. Generally, if it is a content conflict you use a 3-way merge tool to resolve the conflict. This is no different than if there is a conflict when you do an update. The other type is a tree conflict. Generally, these occur when the path that has a change in the repository doesn't exist in your merge target working copy. Resolving them depends on the conflict and you. For example, in branch you edited foo.cs, but in trunk that file is deleted. So, when you try to merge the edit you get a tree conflict. 3) Is mergeinfo a global or local property ? it seems that whenever a new checkout is done, mergeinfo list matches up with other working copies of the same branch. I'm not sure what you are asking here. Merge info is a subversion property, so of course it will exist whenever you check out. Just like and svn:mime-type property. BOb Any help is appreciated. Sincerely
Reverting an ADD status file after an update tree conflict deletes the file
Perform the following steps... 1.Edit a file in a working copy 2.Delete that file in the repository (with the repo browser) 3.Update your working copy 4.Edit the tree conflict and specify keep working copy 5.The edited file now shows as an add 6.Revert the working copy Observed: The file with the add status is deleted. Expected: The add is removed and the file remains. Basically this is the behavior you get when you revert a file that you just added. I would expect reverting an added file to do the same thing whether the file was marked as add from an update or from just adding it. --- I reported this on the TSVN list and got a response of that how svn does it. Doesn't this go against the do no harm mantra? BOb
RE: Reverting an ADD status file after an update tree conflict deletes the file
On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer bob.arc...@amsi.com wrote: Bert, But, this isn't a merge it is an update. If I revert the add I lose all the changes I made in step 1 of my steps below. I might have made a few hundred changes. Granted, I probably shouldn't do the revert without copying the file off somewhere... but those local modifications I made are NOWHERE in this case and can't be recovered if my local copy of the file is deleted. But, but ... isn't 'revert' always a lossy operation? If you revert a locally modified file you also lose your local modifications. But, but, shouldn't then a revert, revert back to the pristine of my working copy, which is the local file without my modifications? I'm not even seeing that, which would somewhat make sense in my head. OK, if you revert a normal 'add', svn will keep the local file. But as Bert said, if you revert an 'add with history' (A +), which seems to be the case here, svn will just throw away whatever is there, exactly like when you revert a Modified file. There is no revert only the add, but keep the local mods operation. Ok, but bottom line... subversion has TRASHED my local changes. This was really surprised me, and in a bad way. Granted, I only found this in a test and didn't actually lose important modifications. BOb
RE: Reverting an ADD status file after an update tree conflict deletes the file
On Mon, Oct 14, 2013 at 9:26 PM, Bob Archer bob.arc...@amsi.com wrote: On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer bob.arc...@amsi.com wrote: Bert, But, this isn't a merge it is an update. If I revert the add I lose all the changes I made in step 1 of my steps below. I might have made a few hundred changes. Granted, I probably shouldn't do the revert without copying the file off somewhere... but those local modifications I made are NOWHERE in this case and can't be recovered if my local copy of the file is deleted. But, but ... isn't 'revert' always a lossy operation? If you revert a locally modified file you also lose your local modifications. But, but, shouldn't then a revert, revert back to the pristine of my working copy, which is the local file without my modifications? I'm not even seeing that, which would somewhat make sense in my head. That's indeed pretty strange. I didn't realize that. But even then you would have lost your local changes, no? Indeed. But, then I would have slapped my head and said, Self (that's what I call myself), it just did what you told it to do. ;) Once again though, to repeat, I am 100% used to when reverting an ADD the file isn't removed. My tiny brain doesn't know ADD from ADD with History from a black hole. OK, if you revert a normal 'add', svn will keep the local file. But as Bert said, if you revert an 'add with history' (A +), which seems to be the case here, svn will just throw away whatever is there, exactly like when you revert a Modified file. There is no revert only the add, but keep the local mods operation. Ok, but bottom line... subversion has TRASHED my local changes. This was really surprised me, and in a bad way. Granted, I only found this in a test and didn't actually lose important modifications. You asked it to trash you local changes. That's precisely what revert is for. Ok, I think the underlying problem is that svn currently does a lousy job at helping users resolve tree conflicts. You're really on your own, and have to improvise. Perhaps it's not even possible to resolve this kind of tree conflict with standard commands (without moving the modified file aside, and moving it back etc). So I can perfectly imagine that you get misled into trying 'revert' to get out of the nasty situation. All I can suggest at this time is: never revert something if it still contains uncommitted changes. If you're unsure what will happen, make a backup copy of your local mods first. Perhaps. If there were a true life issue I might have said... no, that file was deleted for a reason, so I don't want to re-add it, I want to take my code changes and apply them in the correct new place. So, I'll just revert this ADD (which I know from past experience will just keep my local file) and find the correct place to apply these changes... N... that algorithm I spend 4 hours on is gone... DAMN YOU NEWMAN!!! (I mean subversion!) BOb
RE: svn 1.8.3 on windows often crashes
W dniu 2013-10-04 15:04, Ivan Zhakov pisze: On 4 October 2013 17:00, Karol Szkudlarek ka...@mikronika.com.pl wrote: W dniu 2013-10-04 14:50, Ivan Zhakov pisze: On 4 October 2013 16:44, Ivan Zhakov i...@visualsvn.com wrote: I'm trying to use the latest 1.8.3 64-bit version of svn client: CollabNetSubversion-client-1.8.3-1-x64.exe but several times crashes. In attachement are log and dmp. Hi, The attached dumps and logs doesn't have debug symbols included, this we're unable to investigate the issue. I recommend you contact company produced this binaries (CollabNet) or try to reproduce problem with other Subversion binaries distribution and contact them. Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Well, yes it looks like exactly my problem. Thanks for info about. When the 1.8.4 will be released? Now its very annoying crash. I do 'svn log' very often. :-) There is no specific schedule for patch releases. Usually they come not less often than every month and if important fixes are waiting for release. Subversion 1.8.3 was released 29 August 2013. Hello again Ivan, Now we have 14 of October (so we have roughly more then 1 month from 1.8.3 release) and I'm still stuck with crashes of subversion 1.8.3. Please tell me ss it possible to back to 1.7.x series or not?! Of course it is. Of course, there is no way to downgrade a working copy that I am aware of, so you would have to do a clean checkout. BOb Or somebody from subversion release managers could answer me my question about when will be 1.8.4 released with fix for #4425?! Regards, Karol Szkudlarek -- Karol Szkudlarek Head Of Software Development DCIO Mikronika, HQ Poznan Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
RE: SVN Blame Returns Corrupt Data
On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just changed every line. That's exactly what I meant. You're correct with how the blame is handled. I committed the UTF-8 copy to a test branch, diff'd, and it showed every line as being changed. Unfortunately it looks like this is our best option. Yep, we have done the same thing. As a matter of fact, I just over the past few days rescripted all our database scripts to be UTF-8 since merging them just doesn't work correctly when they are UTF-16 even if you remove the binary mime type. On Thu, Oct 10, 2013 at 7:07 PM, Ben Reser b...@reser.org wrote: At current blame is not UTF-16 aware. It's not just blame that isn't... the diff engine, or whatever detects file types always considers UTF-16 files to be binary. If you add a UTF-16 file you see that svn adds the application/octet-stream mime type. There is an issue in the bug database about this from when I reported/complained about it... however it hasn't been addressed. I'm surprised still at this time that svn still can't support UTF-16 text files as text wrt adding, diffing, blaming, etc. BOb About a year ago there was a patch (actually they just reposted an entire copy of blame.c) posted that helped, but it really didn't go anywhere since the original poster didn't continue following up. Perhaps you'll find the above useful. Patches are of course welcome. I'll take a look at that this weekend. Thanks for all the input everyone. On Thu, Oct 10, 2013 at 7:07 PM, Ben Reser b...@reser.org wrote: On 10/10/13 12:17 PM, T.J. Perovich wrote: On Thu, Oct 10, 2013 at 2:27 PM, Ryan Schmidt subversion-20...@ryandesign.com mailto:subversion- 20...@ryandesign.com wrote: Sounds like you've converted the file from UTF-8 to UTF-16. Thanks, you're absolutely right. It changed from UTF-8 to UTF-16LE. Any idea how to go about fixing it elegantly? We have about 3 months of commits since this happened. Diff's in the GUIs have been working fine and we don't blame too often which is why it was never noticed. At current blame is not UTF-16 aware. About a year ago there was a patch (actually they just reposted an entire copy of blame.c) posted that helped, but it really didn't go anywhere since the original poster didn't continue following up. https://mail-archives.apache.org/mod_mbox/subversion- dev/201207.mbox/%3CCAAF0CB13B282344AF95AD2DE3D1962215627A3C%40 DAG-B.nexon.corp%3E and the followup https://mail-archives.apache.org/mod_mbox/subversion- dev/201208.mbox/%3CCAB84uBVVrHFfQyEA5pF5gStMpXz+RH2jKvdvCQsCO cjv+rq...@mail.gmail.com%3E Perhaps you'll find the above useful. Patches are of course welcome.
RE: SVN Blame Returns Corrupt Data
On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just changed every line. That's exactly what I meant. You're correct with how the blame is handled. I committed the UTF-8 copy to a test branch, diff'd, and it showed every line as being changed. Unfortunately it looks like this is our best option. Yep, we have done the same thing. As a matter of fact, I just over the past few days rescripted all our database scripts to be UTF-8 since merging them just doesn't work correctly when they are UTF-16 even if you remove the binary mime type. On Thu, Oct 10, 2013 at 7:07 PM, Ben Reser b...@reser.org wrote: At current blame is not UTF-16 aware. It's not just blame that isn't... the diff engine, or whatever detects file types always considers UTF-16 files to be binary. If you add a UTF-16 file you see that svn adds the application/octet-stream mime type. There is an issue in the bug database about this from when I reported/complained about it... however it hasn't been addressed. I'm surprised still at this time that svn still can't support UTF-16 text files as text wrt adding, diffing, blaming, etc. It's quite simple: no-one has written the necessary code. While I can understand it's an interesting feature for Windows users, most Subversion developers have other things to do. This being a volunteer project, and most of us do not use Windows, you can hardly expect anyone to spend several weeks on solving a problem that has a perfectly simple workaround. Since UFT-8 and UTF-16 can be interchanged without data loss, there are other, much more important things to do in Subversion. I appreciate all that you said. I didn't expect that UTF-16 was so uncommon in non-Windows OSes. A large number of dev tools that I work with on Windows, especially the Microsoft tools default to creating UTF-16 files. I disagree with your can be converted without data loss. If you need UTF-16 then you need it. Also, if you are working in an international team and you have developers with other language Oss which have different code pages then what you see when you look at a UTF-8 file might be different than what I see. So, when I say I'm surprised I only say that with the knowledge that the internet has made the world very flat and I'm sure there is much more collaboration amoungs people that use different languages and work on apps that need to deal with international languages, etc. I'm not dissing the devs in any way. To turn your argument around: I'm surprised no Windows user has yet written a patch for Subversion to make it support UTF-16 ... If I knew how to I would. While I work with C# and I'm sure C is similar it is probably much different. If a svn dev would mentor me through it, and perhaps tell me what modules would need to be modified I would be happy to take a whack at it. BOb
RE: SVN Blame Returns Corrupt Data
On 11.10.2013 16:55, Bob Archer wrote: On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just changed every line. That's exactly what I meant. You're correct with how the blame is handled. I committed the UTF-8 copy to a test branch, diff'd, and it showed every line as being changed. Unfortunately it looks like this is our best option. Yep, we have done the same thing. As a matter of fact, I just over the past few days rescripted all our database scripts to be UTF-8 since merging them just doesn't work correctly when they are UTF-16 even if you remove the binary mime type. On Thu, Oct 10, 2013 at 7:07 PM, Ben Reser b...@reser.org wrote: At current blame is not UTF-16 aware. It's not just blame that isn't... the diff engine, or whatever detects file types always considers UTF-16 files to be binary. If you add a UTF-16 file you see that svn adds the application/octet-stream mime type. There is an issue in the bug database about this from when I reported/complained about it... however it hasn't been addressed. I'm surprised still at this time that svn still can't support UTF-16 text files as text wrt adding, diffing, blaming, etc. It's quite simple: no-one has written the necessary code. While I can understand it's an interesting feature for Windows users, most Subversion developers have other things to do. This being a volunteer project, and most of us do not use Windows, you can hardly expect anyone to spend several weeks on solving a problem that has a perfectly simple workaround. Since UFT-8 and UTF-16 can be interchanged without data loss, there are other, much more important things to do in Subversion. I appreciate all that you said. I didn't expect that UTF-16 was so uncommon in non-Windows OSes. A large number of dev tools that I work with on Windows, especially the Microsoft tools default to creating UTF-16 files. I disagree with your can be converted without data loss. If you need UTF- 16 then you need it. Also, if you are working in an international team and you have developers with other language Oss which have different code pages then what you see when you look at a UTF-8 file might be different than what I see. I don't follow. Both UTF-16 and UTF-8 are complete representations of the Unicode character set. Exactly the same code sequences can be represented in both encodings. You can convert from UTF-16 to UTF-8 and back and get exactly the same sequence of bytes. Ok, I have to back pedal here a bit. You are correct, UTF-8 is a Unicode format and can store all characters. It's not a UTF-8 vs UTF-16 issue (Friday senior moment). What I recall being told by one of the subversion developers was that subversion only supported the ASCII character set and while UTF-8 was compatible with ASCII it didn't truly support Unicode files. However, this blog entry seems to dispute that: http://rhubbarb.wordpress.com/2012/04/28/svn-unicode/ Would adding that mime-type to this file fix the blame issues this user is seeing? BOb
RE: SVN Blame Returns Corrupt Data
On 11.10.2013 17:19, Bob Archer wrote: On 11.10.2013 16:55, Bob Archer wrote: On 11.10.2013 15:58, Bob Archer wrote: On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just changed every line. That's exactly what I meant. You're correct with how the blame is handled. I committed the UTF-8 copy to a test branch, diff'd, and it showed every line as being changed. Unfortunately it looks like this is our best option. Yep, we have done the same thing. As a matter of fact, I just over the past few days rescripted all our database scripts to be UTF-8 since merging them just doesn't work correctly when they are UTF-16 even if you remove the binary mime type. On Thu, Oct 10, 2013 at 7:07 PM, Ben Reser b...@reser.org wrote: At current blame is not UTF-16 aware. It's not just blame that isn't... the diff engine, or whatever detects file types always considers UTF-16 files to be binary. If you add a UTF-16 file you see that svn adds the application/octet-stream mime type. There is an issue in the bug database about this from when I reported/complained about it... however it hasn't been addressed. I'm surprised still at this time that svn still can't support UTF-16 text files as text wrt adding, diffing, blaming, etc. It's quite simple: no-one has written the necessary code. While I can understand it's an interesting feature for Windows users, most Subversion developers have other things to do. This being a volunteer project, and most of us do not use Windows, you can hardly expect anyone to spend several weeks on solving a problem that has a perfectly simple workaround. Since UFT-8 and UTF-16 can be interchanged without data loss, there are other, much more important things to do in Subversion. I appreciate all that you said. I didn't expect that UTF-16 was so uncommon in non-Windows OSes. A large number of dev tools that I work with on Windows, especially the Microsoft tools default to creating UTF-16 files. I disagree with your can be converted without data loss. If you need UTF- 16 then you need it. Also, if you are working in an international team and you have developers with other language Oss which have different code pages then what you see when you look at a UTF-8 file might be different than what I see. I don't follow. Both UTF-16 and UTF-8 are complete representations of the Unicode character set. Exactly the same code sequences can be represented in both encodings. You can convert from UTF-16 to UTF-8 and back and get exactly the same sequence of bytes. Ok, I have to back pedal here a bit. You are correct, UTF-8 is a Unicode format and can store all characters. It's not a UTF-8 vs UTF-16 issue (Friday senior moment). What I recall being told by one of the subversion developers was that subversion only supported the ASCII character set and while UTF-8 was compatible with ASCII it didn't truly support Unicode files. However, this blog entry seems to dispute that: http://rhubbarb.wordpress.com/2012/04/28/svn-unicode/ Would adding that mime-type to this file fix the blame issues this user is seeing? I think the user is just very lucky. Subversion does not actually try to interpret the svn:mime-type property, other than to determine whether to treat a file as text or binary. (The comment is correct in that the proper parameter is charset=, not encoding=, but that's not important for this discussion). Subversion's merge algorithm depends on being able to detect line endings in the file, and always scans the file as a sequence of bytes. There are several ways to represent line endings in a UTF-16 file (shown here as hex byte sequences): * 00 0A (Unix newline, UTF16-BE) * 00 0D 00 0A (Windows newline, UTF16-BE) * 0A 00 (Unix newline, UTF16-LE) * 0D 00 0A 00 (Windows newline, UTF16-LE) * 24 24 (Unicode newline, same in LE and BE) Subversion, however, expects one of the following newline sequences: * 0A (Unix newline) * 0D 0A (Windows newline) My best guess as to what's happening is that the 0A bytes, a.k.a. the ASCII newline character, are interpreted as the end-of-line markers, and the zero bytes are treated as part of the text. In most cases, the result will be close to correct, as long as there are no conflicts in the merge -- because Subversion will not emit conflict markers in UTF-16. Of course, if someone used the U+2424 newline code point instead, then in the worst case, the whole file would be interpreted as a single line. -- Brane Great information.. thanks for that. Bottom line is use UTF-8 for your text files and svn will be happy and work correctly. How hard would it be to create
RE: SVN Blame Returns Corrupt Data
On Oct 10, 2013, at 11:29, T.J. Perovich tjperov...@gmail.com wrote: I'm having trouble running svn blame on a particular file. It's returning garbage. In TortoiseBlame: 3341 TJP ÿþO 3341 TJP In the command line: 3341TJP ■O 3341TJP The file is 10.1k lines, not 2. If I run the blame from revision 0 to 3341 it returns the correct information. In WinMerge and TortoiseMerge, diffing the files shows about 10 lines changing between 3340 and 3341 (it was merge). However, the command line diff shows the entire contents being changed with spaces between every character. So End Class reads E n d C l a s s, etc.. Diffing a merge post-rev# 3341 show the same spaces between every letter. svn diff -r 3341:3489 svn://... @@ -20032,7 +20058,7 @@ F i l l _ d d l L o c a t i o n ( ) F i l l _ d d l C o u n t r y ( ) Sounds like you've converted the file from UTF-8 to UTF-16. Another strange thing is it's marking these as lines 20,032 and 20,058. But in Notepad++ they are lines 10,026 and 10,031. The line numbers in pre-rev# 3341 diffs match up between the Notepad++ and command line fine. Sounds like the line endings changed as well. Sigh... if only svn would support Unicode encodings. BOb
RE: SVN Blame Returns Corrupt Data
Guten Tag T.J. Perovich, am Donnerstag, 10. Oktober 2013 um 21:17 schrieben Sie: Any idea how to go about fixing it elegantly? Simply convert it back using your method of choice, Notepad++ should be able to handle this. Mit freundlichen Grüßen, Thorsten Schöning I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just changed every line. However, at this point blame is probably wrong anyway, because it is showing every line has been changed by whomever changed all the line endings. Bottom line, I think he stuck with it. BOb
RE: tree conflict in merge after deleting and re-adding files
Hi All, TortoiseSVN 1.6.16, Build 21511 - 64 Bit , 2011/06/01 19:00:35 Subversion 1.6.17, apr 1.3.12 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0d 8 Feb 2011 zlib 1.2.5 We have a problem. We have a trunk and a branch, and wanted to merge changes from branch to trunk. Due to some heavier file-conflicts I'we deleted foo.txt in trunk in SVN, copied it from branch and added again. Now I now it was a mistake. Now if we try to make merge, we always get tree conflict on foo.txt - its contents are already identical in trunk and branch. I know that the discontinuity in foo.txt for a range of revisions, so the lack of ancestry causes that. foo.txt was already deleted and re-added in branch by other developer. We have already tried a range of solutions found on the web, but no success. Is there a way to tell SVN to forget this tree conflict thing for ever? thank you in advance. Best regards: Balázs If you do a merge, and resolve the tree conflict, and then commit the merge... subsequent merges will no longer try to merge in the delete change and you shouldn't see further issues. If you keep seeing the same conflict, it sounds like you aren't committing the merge-info that is set on the project root. (you should always merge from the project root). BOb
RE: Breaking up a monolothic repository
Am 10.09.2013 19:45, schrieb Thomas Harold: When we moved from a monolithic repository to per-client repositories a few years ago, we went ahead and: - Rebased the paths up one or two levels (old system was something like monolithicrepo/[a-z]/[client directories]/[job directory]) so that the urls were now clientrepo/[job directory]. That was a tricky thing to do and we had to 'sed' the output of the dump filter before importing it back. It broke a few things, such as svn:externals which were not relative-pathed, but was worth it in the long run so that our URLs got shorter. - Made sure that the new repos all had unique UUIDs. - Renumbered all of the resulting revisions as we loaded things back in. But we didn't have to deal with any bug tracking systems that referred to a specific revision. And having lower revision numbers was preferred, along with dropping revisions that referred to other projects. I'm now facing the same problem. My users want the rebasing, but during the dump/load instead of after the fact (apparently, it causes issues with their environment when they need to go back to an earlier revision to reproduce something). They also want to keep the empty revisions (for references from the issue tracker). Wouldn't it be much simpler to keep the current repository as a read only archives and move the HEAD of each project into its own repo? I haven't tried it with svnadmin dump followed by svndumpfilter (I don't think it has that capability). I've tried svnrdump (from svn 1.7), it resulted in either a new repository with the full path included (rdump/load all revs) or an interesting failure mode with a missing node during a copy operation when rdump -r revision_after_path:HEAD was used I've also tried using svnsync, but that also results in the full path included, no rebasing. How did you do it? Also, am I missing something that has been included in a current svn version? Cheers, Ulli
RE: Copy changes from one branch to another
On Mon, Sep 30, 2013 at 2:45 PM, Grierson, David david.grier...@bskyb.com wrote: Um ... why? Well, the way has come a long way and to reproduce it would take me a lot of time so i would please you and the others to just take it as given. Wouldn't this mean that trunk and branch A are identical at all times - in which case what's the purpose of branch A over trunk? Well, in case of our teams code base this is true. But our teams code base only makes up a small part of the whole trunk, so there are some dependencies (code and compiled libs) which are different in the two branches. And we do have to run tests against both branches to make sure it works with the different dependencies. Does that make sense? Then this should not be automated. There is always the possibility of a conflict during the merge, and a person will have to resolve those. BOb Best Regards, Sven -Original Message- From: Sven Richter [mailto:sver...@googlemail.com] Sent: 30 September 2013 13:29 To: users@subversion.apache.org Subject: Copy changes from one branch to another Hi, I have the following setup trunk branch A (created from trunk) | | | | | | Now, what I want to do is only commit my changes to the trunk and make sure that every committed change is replicated into branch A. This should be an automatic commit, triggered by the commit to trunk, while being aware of the fact that no other changes should be done in branch A but the autocommit from trunk. Another would-like requirement is that the commit metadata like author and commit time/date are kept, but this is not a must have. Is that possible with svn, maybe with autocommit hooks? If not, what other way would you see to achieve that? Best Regards, Sven Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
RE: Copy changes from one branch to another
On Mon, Sep 30, 2013 at 3:14 PM, Andrew Reedick andrew.reed...@cbeyond.net wrote: Post commit script that deletes branch A and then recreates branch A from trunk, i.e. make branch A effectively a tag. Since the delete and copy are server side commands, no workspace is needed to make it work. However this will fail if (when) you need to make custom changes on branch A. But that has the effect that i will have all the changes from trunk in branch A, which is not what I want. I only want some certain changes inside there, the changes committed from our team. Best Regards, Sven Common stuff should be brought in with Externals rather than a merge. That may be a better use case considering what you are asking for.
RE: Shared branch vs single branch
On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer bob.arc...@amsi.com wrote: It really depends. I think all work for a specific release should be done in a single branch/folder. Many people follow the stable trunk model. In this model you generally do all work on trunk and then branch for a release. This is the same model svn itself is developed under. In this model you would also use what are called feature branches. This is generally for a feature/use case that will take more than a day to complete or will be worked on by more than one developer. Once again, it's up to the people not the tool to ensure your release management is done properly. Well, sort-of. It is always a good idea to (a) include tests for new code and (b) have a workflow that ensures that the tests are run and that someone checks the results. Expecting one person to never make a mistake just doesn't always work out. Isn't is up to the people to put those processes in place? To create the correct workflow? To write the automation? I don't think I ever said it should be ONE person's responsibility to manually do this work. Where did I say that? BOb A general rule can't cover all cases, but in general I think the longer you let branches diverge with isolated work, the more likely they are to have conflicting changes that will take extra work to resolve when you finally do merge. -- Les Mikesell lesmikes...@gmail.com
RE: Shared branch vs single branch
What are some of the pros/cons of using a single/shared branch versus the private developer branch? We are having an internal debate within the team where the idea of a single/shared branch was proposed in reaction to two specific issues: 1. In the merge to trunk from individual developer branches, some code was lost. It remains unclear whether it was user error on part of the person doing the merge or the tool which caused the problem. In at least one case, a file was partially merged. It was the user that did the merge. It will only commit what you tell it to commit. This is a people problem, not a branch strategy issue. 2. The combined functionality (features assigned to two different developers) was not included in the final application build and delivery. In this case, the assignments were made months apart and one feature was delivered without the other. Once again, a people problem. The expectation is that a shared/single branch will correct these issues. I am curious to know what advice others can offer and what (if any) potential issues we may experience with the new paradigm. Thanks. Amad. It really depends. I think all work for a specific release should be done in a single branch/folder. Many people follow the stable trunk model. In this model you generally do all work on trunk and then branch for a release. This is the same model svn itself is developed under. In this model you would also use what are called feature branches. This is generally for a feature/use case that will take more than a day to complete or will be worked on by more than one developer. Once again, it's up to the people not the tool to ensure your release management is done properly. BOb
RE: Push ?
Guten Tag Dan White, am Sonntag, 15. September 2013 um 17:32 schrieben Sie: Searching for a solution found one possibility: Check out a copy on the subversion server and then rsync to the final client destination. How is rsync more secure than accessing the client using SSH and use svn update? SSH has some options to limit access and possibilities. For example ForceCommand sounds interesting: http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for- port-forwarding I was hoping to find a one-step solution rather than a two step. How about polling on the client? Issueing a svn update every some seconds shouldn't hurt client and server much. This is what CI servers do... Cruise Control, Team City, Jenkins, etc. BOb
RE: Breaking up a monolothic repository
-Original Message- From: t...@elba.apache.org [mailto:t...@elba.apache.org] On Behalf Of Trent W. Buck Sent: Monday, September 09, 2013 11:38 PM To: users@subversion.apache.org Subject: Re: Breaking up a monolothic repository Les Mikesell lesmikes...@gmail.com writes: On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck trentb...@gmail.com wrote: Ryan Schmidt subversion-20...@ryandesign.com writes: As someone used to Subversion's usually sequential revision numbers, that bugs me aesthetically, but it works fine. I think that's the crux of it. Have you checked if the users have/need anything (emails, ticket system, etc.) that refer to specific revisions or the history of changes made there? It seems kind of drastic to throw that away because you think the numbers aren't pretty enough. That is an extremely valid point. I'll check. Also part of the reason to split up the repos is to make access control easier, and it looks bad if Alice (who should have access to project 1 but not project 2) can see Bob's old commit metadata to project 2, even if she can't see the commit bodies after the split. How does this work now in the combined repository? Right now, they don't have it with the combined repo. Anyone in the svn group can read everything. (This is one of the reasons they want to break up the single repo into per-project repos.) You should knock the reason off the list. You can set up path based authorization fairly easily. (especially compared to braking it up into multiple repos.) BOb
RE: how to simply : $svn update ?
I do '$svn status' and get that I am at a certain revision Type 'svn help' for usage. cpu:/dirsvn update At revision 32933. This leads me to believe that I am fully sync'd with the repo since it pulled nothing back. --- I do svn status and see something surprising cpu:/dirsvn status ? src/main ? src/test/java ? src/test/resources/META-INF means the above files are not added and do not exist in the remote repo (but yes they indeed exist there, If I do a fresh checkout, I see these directories there with many files. --- I have not touched this project, and have no idea why it is out of whack. What I want to do is force sync with the repo. When I google on this, I am taken down long tunnels in various caves with so many confusing solutions. In my head, I think I should simply be able to do: $svn --force update or something simple like that. How do I do this? Try svn cleanup Then check your status. Bob
RE: Switching
-Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Thursday, August 22, 2013 12:21 PM To: users@subversion.apache.org Subject: Re: Switching How would you like Subversion to work in your case? From my understanding it breaks down to something generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about? I don't see how this problem can be solved by any tool. Part of his frustration is that the files in question are listed in the global- ignores. So... maybe a feature request to have a 'svn switch' option to take global-ignores into consideration when deciding whether to keep or delete local files? I thought svn's policy was do no harm... so un-versioned files are never deleted by default. BOb
RE: Strange behavior
Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. Search for global-ignores in the single page version of the redbook: http://svnbook.red-bean.com/en/1.7/svn-book.html Here's infor about runtime configuration: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea BOb JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:02 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
Brenden Walker bkwal...@drbsystems.com writes: svn: E175002: Adding directory failed: COPY on /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 Failed Dependency) Turned out that another developer had locks on several files. Confirmed that was the problem. A more specific error message would have been handy here. Can you describe how to reproduce the problem? What sort of locks prevent a COPY? Orphaned locks perhaps? They were working copy locks from another developer. I asked him to try the build himself to see if it allows the user who holds the lock to svn copy, haven't heard back from that. Breaking the locks allowed me to do an SVN copy. I haven't tried reproducing, but I certainly can if that would be helpful. Are you sharing working copies with multiple people? BOb
RE: SVN performance -URGENT
Hello Team, We are using subversion 1.7 which is hosted in linux and apache is being used along with this. The linux is very powerful but we are facing a major issue during the SVN operation from the windows system. Windows system : Microsoft windows XP 2.85 GB of Ram tortoisesvn 1.7 Windows system is based in london and SVN server(linux system) is located in New york .When i checked the bandwidth using iperf from the windows system ,it is showing as 35.5MB . So when i do a checkout of repository ,it get message at last saying . 2200MBytes transfered at 143 mins.Which is very annoying. According to bandwidth etc etc it should finish the checkout in few mins. May i know where is the bottleneck? My first question would be, given the same machine being on the same LAN as the server, what is the checkout time? One of the biggest slowdowns on windows is Virus Software. Are you running any. Also, have you tested using the svn command line to do the checkout to see if it is any faster? Most virus software ignores command line apps. BOb
RE: SVN performance -URGENT
Please stop top posting. I tried in the same server where svn is hosted but there also it is taking too much of time I e it is taking 110 mins to checkout the 2200 Mbytes of data(in Windows it took 143 mins). I have not tried the command line option.Could you please tell how to do it from windows machine? If you installed the command line option when you installed tortoise svn from a command line you would cd to your development root and use the a command like... svn co http://myserver/svn/path workingcopyfoldername In windows when the checkout is completed I got a message saying 361 Mbytes(different repository) transferred in 102 mins,but it is showing as 1.13GB when I checked the folder size.Why there is so much of difference . Ideally for 361 Mbytes,the checkout should complete in few mins but it is taking 102 mins. :-( The working copy is generally 2x the size of the files in it, since the .svn folder contains the pristine copies of your working copy. This is how svn can do diffs against changed items In your working copy without hitting the server, and also how it can do reverts. I cannot turn off the anti-virus part and check. That's unfortunate. Are you able to at least tell it to ignore your development root folder. We have corporate virus software too, but I am allowed to exclude folders, so I exclude c:\users\bob\development. Virus Software can really mess up svn and cause perf issues. Hello Team, We are using subversion 1.7 which is hosted in linux and apache is being used along with this. The linux is very powerful but we are facing a major issue during the SVN operation from the windows system. Windows system : Microsoft windows XP 2.85 GB of Ram tortoisesvn 1.7 Windows system is based in london and SVN server(linux system) is located in New york .When i checked the bandwidth using iperf from the windows system ,it is showing as 35.5MB . So when i do a checkout of repository ,it get message at last saying . 2200MBytes transfered at 143 mins.Which is very annoying. According to bandwidth etc etc it should finish the checkout in few mins. May i know where is the bottleneck? My first question would be, given the same machine being on the same LAN as the server, what is the checkout time? One of the biggest slowdowns on windows is Virus Software. Are you running any. Also, have you tested using the svn command line to do the checkout to see if it is any faster? Most virus software ignores command line apps. BOb __ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Emails are monitored by supervisory personnel in jurisdictions where monitoring is permitted. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
RE: SVN performance -URGENT
Bandwidth is 35.4 MBytes/sec from my system(London) to server(New york) when i checked with iperf tool. WOW! That is insanely fast. Are you sure its not 35 Mbps (Mega bits!!)? Google Fiber that everyone covets is 1 Gbps (Giga bit per second) or 1024 Mbps or 128 MBps. At 35 Mbps it would take a little less than 7 minutes to transfer. That is assuming constant speed. Can you copy the folder from the machine in London to the machine in New York in under 7 minutes? At 35 MBps it would take under a minute! We are using LDAP AuthzLDAPAuthoritative off AuthType Basic AuthBasicProvider ldap AuthName Windows Credentials As per message after checkout in TortoiseSVN GUI = 368 Mbytes transfered. Actual folder size = 1.15 GB(1236706079 bytes) Number of files = 201,712 Folder = 21,707 Guess this inculdes the .svn folder as well. Thanks, Anup I'm not sure why there would be that much overhead with SVN, I guess it does no caching. One the plus side, you only have to check out once. ;) Have you tried to check out some large public stuff? For example, check out the subversion repository and see how long that takes. Was the command line checkout time any different? From: kmra...@rockwellcollins.com [mailto:kmra...@rockwellcollins.com] Sent: 01 August 2013 15:20 To: Bob Archer Cc: Somashekarappa, Anup (CWM-NR); users@subversion.apache.org Subject: RE: SVN performance -URGENT Bob Archer bob.arc...@amsi.com wrote on 08/01/2013 09:02:32 AM: We are using subversion 1.7 which is hosted in linux and apache isbeing used along with this. The linux is very powerful but we are facing a major issue during the SVN operation from the windows system. Windows system : Microsoft windows XP 2.85 GB of Ram tortoisesvn 1.7 Windows system is based in london and SVN server(linux system) is located in New york .When i checked the bandwidth using iperf from the windows system ,it is showing as 35.5MB . 35.5MB/s or 35.5Mb/s? The first one would be a 284Mb/s connection between London and NY... What is the latency between the client and server? Latency can be a big killer depending upon the authentication used. So when i do a checkout of repository ,it get message at last saying . 2200MBytes transfered at 143 mins.Which is very annoying. According to bandwidth etc etc it should finish the checkout in few mins. May i know where is the bottleneck? The total amount of data transferred shown by TortoiseSVN can sometimes be quite misleading. How big is the working copy that is created? Kevin R. __ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Emails are monitored by supervisory personnel in jurisdictions where monitoring is permitted. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
RE: check out deleted folder
Hi there, my situation is as follows: there's a large svn repository svn+ssh://someserver/reps/maindir/ I only work with the subdirectory svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with such that I used to check it out with svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with what_I_work_with got moved by the maintainers of the main repository in revision r123456 to svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with now I can check it out with svn co svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with in newlocation, commands like svn log, svn blame, ... still work, I see commit messages from before r123456 and changes from r900 are correctly reported by svn blame. what does not work is cd what_I_work_with svn up -r900 since maindir/new_dir/foobar/what_I_work_with doesn't exist in r900. Also the alternate approach checking out what_I_work_with doesn't work since the directory doesn't exist in the trunk svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with neither did switching work: cd what_I_work_with svn switch /old_dir/... Also, I'm hesitant to check out svn+ssh://someserver/reps/maindir due to the large overhead of stuff in there which I don't need (in fact I found it a strong part of svn that subdirectories of a repository are repositories themselves). Is there any way to check out or update to revision r900? I don't think so. Since the canonical name of an item in the repository is a combination of the full path and the rev number (^maindir/new_dir/foobar/what_I_work_with@123456) you can't update a path to a revision in which that path didn't exist. You would have to check out rev900 from the original path. You could try: Svn co -r 900 ^maindir/new_dir/foobar/what_I_work_with@123456 But, I'm not sure if that will work. BOb
RE: check out deleted folder
Hi there, my situation is as follows: there's a large svn repository svn+ssh://someserver/reps/maindir/ I only work with the subdirectory svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with such that I used to check it out with svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with what_I_work_with got moved by the maintainers of the main repository in revision r123456 to svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with now I can check it out with svn co svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with in newlocation, commands like svn log, svn blame, ... still work, I see commit messages from before r123456 and changes from r900 are correctly reported by svn blame. what does not work is cd what_I_work_with svn up -r900 since maindir/new_dir/foobar/what_I_work_with doesn't exist in r900. Also the alternate approach checking out what_I_work_with doesn't work since the directory doesn't exist in the trunk svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with neither did switching work: cd what_I_work_with svn switch /old_dir/... Also, I'm hesitant to check out svn+ssh://someserver/reps/maindir due to the large overhead of stuff in there which I don't need (in fact I found it a strong part of svn that subdirectories of a repository are repositories themselves). Is there any way to check out or update to revision r900? I don't think so. Since the canonical name of an item in the repository is a combination of the full path and the rev number (^maindir/new_dir/foobar/what_I_work_with@123456) you can't update a path to a revision in which that path didn't exist. You would have to check out rev900 from the original path. You could try: Svn co -r 900 ^maindir/new_dir/foobar/what_I_work_with@123456 But, I'm not sure if that will work. BOb Oh, and you can of course check out the deleted path... just provide the peg revision... Svn co ^path/to/file@900 BOb
RE: Question about subversion
Hi there. I have a question about subversion. I think the previous response was quite correct, it mostly all depends. I have a theory on what files should not be on SVN and I would like you to tell me if you agree. If you dont agree can you tell me why please. If you see more files that should not be there, tell me and why. Files who should not be on SVN : . files automatically generated Well, Visual Studio generates designer files when you edit a web form... we do check those in. We also use compass and I check in the compiled .css file. Of course, I would like to no longer do that and have the build server generate it. . files containing specific information about my development environment (so properties files for example) For the most part, yes. We check in the files with a .template in the name and have an init.bat file that copies them out... this way for any initial checkout you at least get reasonable defaults. Our template files also contain the QA connection strings so even a dev without the dbs set up will be able to locally run the ap. (as was said before, it depends). . executable files PS: I am conscious that we can put anything to subversion but I am looking for Best practices Thank you so much Once again, it depends. Many people feel it is a best practice to be able to do a check-out and then build the file without having to do any specific tool installs on your PC. Stuff like NuGet (gems npm whatever) help a lot, since your build can leverage those tools to get the binaries you need to build test. But, sometimes those tools need to be there. For example, we have nant (build tool) and mbunit (test tool) checked in so that the build server doesn't need to have each of those tools installed, and so also we can rev those tools by project rather than having to upgrade all the projects at once. Also, we have some legacy VB6 code in our project and we use binary compatibility, so we need to DLLs checked in. As much as I don't like it. I am also considering moving these to a new repo and linking with external so that we don't get all the repo bloat... I can just blow away the binary repo every year or so. But, yes, for the most part, that artifacts that your project builds aren't checked in.. but sometimes dependencies and tools are checked in as binaries. So the correct answer, as with almost anything in development is, it depends. BOb * Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel. **
RE: please unsubscribe me from the list
It’s users-unsubscribe … BOb From: Alexander Ivanenko [mailto:kito...@mail.ru] Sent: Wednesday, June 19, 2013 3:19 AM To: users@subversion.apache.org Subject: please unsubscribe me from the list Please unsubscribe me from the list, unsubscribe-us...@subversion.apache.orgmailto:unsubscribe-us...@subversion.apache.org seems not to work! Regards, Alexander Ivanenko
RE: Ancestrally Related Error Message
Hello, Code for a new development effort was imported into a developer's branch. Now we want merge his changes to trunk (which is currently empty). I tried the merge from both the command line and the Tortoise GUI and keep running into the ...must be ancestrally related... message.I also tried the ignore ancestry option via the GUI. One, I don't understand why SVN thinks there is even an ancestral relationship betweeen the two locations? Two, how can I do to get around this error message? From your message I assume that your branch install a copy of your trunk, hence not ancestrally related. It thinks there is a relationship because you are doing a merge. I'm not sure why the ignore ancestry doesn't solve the issue though. Since trunk is empty... why not just delete trunk and copy that branch to trunk? BOb
RE: Build on Pre-Commit
Hello, I know this has been asked already, but we would really like to reject any attempt to commit files which would break a project in trunk. The decision to reject the committed files is based on the result of the building process of the project the files being committed belong to. I know that during the pre-commit phase the repository cannot be accessed concurrently, but this is not a problem for us since our buildings are really fast and we can tolerate any delay involved. Are there any tools to achieve what we want? Note that it will be necessary ro recompile the whole project unit, not just the single files being committed. Thanks. I don't think there is ever a 100% certainty that a commit won't break a build even if that commit was ok on another branch. What is the problem you are trying to solve by doing this? One major point of continuous integration is that your builds break early, giving instant feedback so the dev can fix this issue. You can move the problem to a branch. All commits go to a branch and after the branch builds your build server merges that branch to trunk (or whatever) but that may still break the trunk build. This is best dealt with procedures. Do your devs have the same build.bat file (or whatever) that the build server does? They should... this way they can... 1. Make code changes test locally. 2. Update their working copy, run same build/test local that the build server runs. 3. If step two is successful commit to the server. BOb
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/18/2013 08:33 PM, David Chapman wrote: On 5/18/2013 12:01 PM, Zé wrote: On 05/18/2013 07:16 PM, David Chapman wrote: You are pretty insistent that there is One True Way to use branches in development. No, I'm stating that if all a SCM does is track changes made to the contents of a directory and you rely on changes made to that directory to emulate branches, then there are some significant downsides to this approach when compared with SCM systems which do offer support for branching. You've missed the point. You have a specific definition of branching and do not believe that anything else can be called branching. You are confused. This discussion is about how subversion lacks any support for branching, which is quite obvious to anyone who understands and acknowledges that all subversion does is track revision changes to a file system. What you are insistingly referring to as branches is nothing more than a copy of a particular subdirectory (i.e., the trunk) into another subdirectory (i.e., branches), which is nothing more than a plain recursive directory copy operation on a file system. The operation doesn't change its name or nature (tag, trunk, simple server-side directory copy) depending on the directories which are copied around the repository. Is that so hard for you to understand? I disagree here. A branch is more than a plain recursive directory copy operation on a file system. It has ancestry since it is pointed to its parent. This allows for merges from the parent to the branch. Svn log will show the revision history of a file from the branch back up to the parent path. Also blame goes back to the parent history as well. If a branch were only a copy then blame would only show, right after the branch, the person that made the branch. You keep saying svn doesn't support branches yet I use branches every day. While there is no way to list branches it would be possible. I think the current implementation records the parent path in the branch, but not vice versa... I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own. In your message to Thorsten Schöning, you said that branch history should be deleted if the branch is deleted. That is fundamentally in opposition to the definition of Subversion, which is meant to retain all of a project's history. Again, that's wrong. The only thing that leads subversion to track how a subdirectory is copied around in the repository is the fact that this is not a branching operation: this is nothing more than a plain file system operation. The point of this whole discussion is that subversion does not support branching, and therefore subversion users have to rely on the let's copy the trunk directory somewhere in the repo to simulate tags/branches hack to make do. Instead of relying on this hack, subversion would be significantly improved if it actually supported branches. How come you've replied so many times to this discussion if you are so oblivious to what has been discussed so far? snip other misconceptions/ -- Zé
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Guten Tag Zé, am Sonntag, 19. Mai 2013 um 10:20 schrieben Sie: You are confused. This discussion is about how subversion lacks any support for branching, which is quite obvious to anyone who understands and acknowledges that all subversion does is track revision changes to a file system.[...] Is that so hard for you to understand? It seems as hard to understand as it seems to be hard to understand for you that you didn't ever gave any common specification what exactly a branch or tag is. You said something about metadata, but gave no example what this meta data is, besides a name, or why someone should benefit of only top level branches and tags. Ze, Wait... did you say a few message ago that you don't think a branch is a branch, because when you delete the branch the history of the path is still in the repo? That's what your example seemed to show. I think people want obiliterate to deal with that issue. You can delete any path and still see it in the history if you ask for it.. Isn't keeping that history the whole point? BOb
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 9:23 AM, Bob Archer bob.arc...@amsi.com wrote: You are confused. This discussion is about how subversion lacks any support for branching, which is quite obvious to anyone who understands and acknowledges that all subversion does is track revision changes to a file system. What you are insistingly referring to as branches is nothing more than a copy of a particular subdirectory (i.e., the trunk) into another subdirectory (i.e., branches), which is nothing more than a plain recursive directory copy operation on a file system. The operation doesn't change its name or nature (tag, trunk, simple server-side directory copy) depending on the directories which are copied around the repository. Is that so hard for you to understand? You keep saying svn doesn't support branches yet I use branches every day. While there is no way to list branches it would be possible. I think the current implementation records the parent path in the branch, but not vice versa... Of course you can 'list branches' as long as you follow and remember _your_ convention for where they are. You can also delete them to the extent that they don't show up in this list (even though they can still be accessed with peg revision syntax and the actions show in the True, I can look at the branches folder. However, we keep branches for all revisions in the same branches folder. What I meant is I can't be in a working copy with a repo path of ^/trunk and have it tell me what branches (copies) have been made from that path. Once again, a nice to have, but not a must have... since yes, our naming conventions are sufficient to identify the info we need. log history of the parent directory). This is nicer in many ways than just having one special-case 'branch' namespace, especially when you have many projects in the same repository and/or you like to separate your release, QA, and experimental branches so different groups don't have to deal with the clutter from the others. Subversion doesn't force you to follow good conventions (and I think this thread started because someone didn't and the rename of a directory above where they put a branch was recorded as a change in both the branch and its parent), but you can if you want. I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own. Subversion always tracks 'copy from', but not 'copy-to'. In one way it is correct to say that subversion doesn't have a special concept for branches, but it is equally correct to say that every copy is handled like a branch. Right, so this copy-from info is exactly what makes the copy a branch or more than just a file system copy. that's the point I was trying to make. -- Les Mikesell lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
.. snip You keep saying svn doesn't support branches yet I use branches every day. While there is no way to list branches it would be possible. I think the current implementation records the parent path in the branch, but not vice versa... I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own. There are two definitions of branches; svn's definition of a branch (i.e. a dir) and the high-level definition of a branch (theory.) The reason why svn doesn't support branches is because a svn branch is just a dir, a dir that is only a branch because it is given special meaning by Humans. Internally, svn doesn't know or care if a dir is a branch or not. The distinction is important because one of the theoretical benefits of branching is isolation. An outside change shouldn't affect the branch's contents. Unfortunately, changing the parent path of a branch injects a spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop early. This is detailed in my original email that started this thread. True but doesn't the log of ^/projectname1/trunk also change when you commit something to ^/projectname2/trunk ?? Projects aren't isolated within the same repo either. So when people say that svn doesn't have branches, they are saying that a) svn has directory objects, not branch objects, i.e. a svn branch is a branch by human convention only, b) svn dirs lack the special protections expected of branches (e.g. being isolated from outside change), c) svn dirs lack the special abilities expected of branches, such as computing ancestry reliably. Fortunately, in practice, dirs-as-branches works fine for the most part and any limitations tend to be minor. While there is no way to list branches it would be possible. No-ish. In the average case, list branches is easy. Just iteratively run 'log -- stop-on-copy'. However, there are edge cases that prevent list branches from being deterministic or otherwise make determining ancestry complicated. For example, is this a rename (to fix a misspelling) or a case where someone combined two steps: 1) creating a new branch and 2) deleting an obsolete branch? svn copy branches/ofo-1.0 branches/foo-1.0 svn rm branches/ofo-1.0 svn ci ... creates revision 100 ... If I want to find the start of the branch, I run 'svn log --stop-on-copy ^/branches/foo-1.0' which will stop on revision 100. However, svn can't tell me if rev 100 is the start of the branch or whether it's just a spelling fix (in which case I need to run 'svn log --stop-on-copy' again.) Hopefully, the Human who created rev 100 provided a meaningful commit message.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Guten Tag Andreas Krey, am Samstag, 18. Mai 2013 um 22:41 schrieben Sie: You mean like 'I expect tags to be immutable out of the box, and have the VCS not modify them with perfectly normal operations, at least not without adding -f or something to them'? This sounds like Subversion technically supports tags, just with the caveat that you have to deal with -f yourself. From my use case I like that tags are writable by default because that's what I need. Although, truly if there was a tag command that added metadata to a revision which I think someone showed an example of earlier in this thread, you could still use the copy command to get a writeable tag directory like you have now. Frankly, if you are writing to tags it is more like a branch. ;) BOb
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 11, 2013 at 10:50:12PM +0100, Zé wrote: You're missing the point. The point is that subversion could be even better than what it already is if it actually supported branches. OK, I would also like Subversion to get better, so we agree here. Now, what kinds of improvements would you hope to gain from adding a first- class concept called branch to the current system? Keep in mind that adding a new dimension to the current repository data model is a huge amount of work. We need a design spec that is solid, and we need to have a very good idea of how to implement that design, using the current system as a starting point. We need to know how all existing operations will be affected by the extended data model, and how they need to behave in the new data model. We need to define use cases and test cases for any new behaviour. We need to know if and how these changes affect our two network communication protocols, and perhaps implement changes there. And it also needs to be backwards compatible all the way back to SVN 1.0. That is only true if this change is 1.something. But, if it is 2.0 then the svn rules allow for a break in backward compatibility. What I don't understand is why someone argues about how git does something is better yet uses svn. Use the tool that works for you, or works the way you expect a tool to work. BOb
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/13/2013 10:04 AM, Bob Archer wrote: What I don't understand is why someone argues about how git does something is better yet uses svn. Use the tool that works for you, or works the way you expect a tool to work. Oh, I'm sure if we tried we could all think up plenty of reasons why someone might argue the superiority of one tool over another and yet use the other. Perhaps the superiority isn't universal -- only some features are better, while some lack. Perhaps the choice of tool isn't available for one reason or another. Whatever. It hardly matters here -- on this list -- why someone who likes Git also uses Subversion. What matters is the desired outcome of the discussion. This list is about Subversion. OtherVCSystem fanboyism isn't welcome here, not because it's fanboyism (which is just intellectually pathetic) but because it's off-topic. But merely pointing out things that Git does better (in someone's approximation) than Subversion isn't necessarily fanboyism. And if the point of comparing Subversion to Git or Hg or OtherVCSystem is to find ways to make Subversion a better product, that's completely on-topic and welcome (so long as the discussion is handled maturely). Yes, I get what you are saying. But, to claim the way svn supports branches and tags is a hack doesn't seem like a productive conversation. It is far from a hack and that statement dismisses all the hard work of design and implementation that went into svn almost dismissing the whole team many of which are volunteers. It would be nice if branches could become a first class object with the branch command being very specific. But, what we have is far from a hack if you understand how it works. I would like to see more first class support for projects and/or defining a project root. For example, perhaps there can be an svn:projectroot property that must be on a folder and the branch/merge command will only work on project roots. If that is done of course the maintain backward compatibility there could be a switch in the client config to allow for bypassing this requirement, or perhaps the --force switch could do it. Also, a property can be place on a branch so that tooling can know it is actually a semantic branch rather than just a fork (copy).
RE: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, May 13, 2013 at 12:23 PM, Andreas Krey a.k...@gmx.de wrote: On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote: ... Maybe it is just my misconception, but I've always thought of the difference between svn and git as being that svn conceptually tracks complete revisions although sometimes it might generate or store differences for some operations or internal storage convenience, where git tracks changesets although it often has to generate complete revisions. That indeed is just a misconception. git even goes to define exactly how each commit (aka revision) is stored including its checksum. This even though is it then going to internally store that in a dense packfile format. What it computes internally or uses as an internal storage isn't quite the point. Svn would also always compute the differences even though it really only cares about the full revisions.What does git do if you try to double-merge a change? Does it know about the previous merge by its changeset commit id, look at the contents that are already present, or just do it twice? Been a while since I have really got into the git internals, but I think each changeset has a SHA1 hash... if a changeset with that hash is already in a branch merging won't do anything... there will be nothing to merge. That said, I don't even think you can specify in git what to merge it just merges all the changes. I think it is possible to do a cherry-pick, but I think that creates a diff basically and applies that to the target. BOb The nature of branches seems to relate better to No, the basic difference is that VCS operating on the whole tree can only have branches (and thus merge info) on the whole tree either, so you *can't* go like subversion does and map branches into the tree and need to have them (and tags) as a separate concept. I can see why it might be a problem to support concurrent nested branch changeset roots but that scenario is problematic any way you look at it. Why would it be a problem to support parallel branching roots - perhaps with some enforcement on the source/dest top levels having some common parent? SVN, instead of having branches as a separate concept, also stores whole trees, but instead additionally stores 'this came from there' or 'that was merged here' as a separate concept. But does 'that was merged here', really know about the commit changeset where the change originated? -- Les Mikesell lesmikes...@gmail.com
RE: trunk naming best practice question
For the trunk, what's the common practice to name a version of the trunk? We have a trunk and it's not ready for branching. We also feel that we need a more specific name for the trunk than what we have now called version=trunk. However, we can't be specific since we don't know what the branch name would be while at the same time, we need to perform daily builds for QA testing. What's the best practice in use with SVN ? Really, it's about whatever works best for you. We no longer use the name trunk on our projects. I guess it works ok if you branch for release... but that wasn't working for us. So, instead of using trunk we use the version number... so in our project you would see... /ProjectName /v1.0.0 /v1.1.0 /branches /feature1 /feature2 /tags Our procedure is to only merge up versions. We build and release from out version path [branch]. Feature branches are created for items that will take more than a day or more than one person is working on it. We fix bugs in the lowest version number that we are still supporting and merge that fix up all the way through our non-released dev version. This also helps us a lot with our build server, because we had to constantly redefine what was in the trunk working copy. This way creating a build project for a new release is much easier... we svn copy the version to the new release version, update the cruise control.net config file that is in the project folder with the new version number, checkout the new version path to the build server, update the ccnet.config root config to point to the new version. We also generally don't build from feature branches, but we could if we wanted to. However, the build scripts would have to be changed a bit since artifacts are copied to a folder based on version number atm. Once again, whatever works best for you. Using a trunk that was never the same version from week to week didn't work for us. We also were doing a lot of cyclic merges and needed a better way. BOb
RE: Blame/annotate not good enough...
On Apr 23, 2013, at 15:56, Daniel Shahaf wrote: Ryan Schmidt wrote on Tue, Apr 23, 2013 at 01:45:49 -0500: 3. If you want the actual source code in the repository to contain these comments, then you're talking about several scripts: one that the developers must invoke in place of svn commit to commit their work, which transforms their files in the ways you desire before committing them, and another that runs as a pre-commit hook and verifies that the incoming commit conforms to these requirements (and rejects the commit if not). Or, more simply, developers run 'commit' normally and a post-commit hook appends the blame-comments. Appends the blame-comments to what? Certainly not to the file in the repository because by post-commit time the commit is already finalized. And you wouldn't want to modify the transaction in the pre-commit hook because that would screw up working copies. Are you suggesting the server should make a second commit after every commit to add the blame-comments? That would totally mess up normal use of svn blame, among the other usual problems. I agree. It seems to me that a CI build process should be generating BLAME audit documents for the auditors that could be checked into another repository. The devs should OWN the source, not the auditors! BOb
RE: merge using same revision number - quick question
Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. (Stop top posting!!!) Thanks all sincerely On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer bob.arc...@amsi.com wrote: Hi All We have a revision that contains a few changed files on the trunk: r345 /usr/ext/a.java /usr/ext/b.java We like to merge this a branch working copy. Can we perform multiple merge svn with the same revision number ? We have a reason to do that; We know it doesnt make sense in this simple example. ie can we have 2 merge svn executions and still produce the same result as a simple merge execution. meaning svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java as opposed to svn merge -c 345 https://test.com/svn/root/src/usr/ext Thanks all. The resulting commit would probably be the same... although I expect the merge info would be applied to the files rather than the folder. Give your simple example a try in a test repo. BOb
RE: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. Thanks for your response. What does elided mean ? Elide simple means remove. We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit Great... if you always do your merges from your project root, you won't see this issue again. How do we stop top posting and adhere to the rules ? We're new. Just put your replys at the BOTTOM of your message, or inline as relevant, rather than at the top of your message. BOb
RE: merge using same revision number - quick question
-Original Message- From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, April 24, 2013 4:26 PM To: Bob Archer Cc: Johan Corveleyn; users@subversion.apache.org Subject: Re: merge using same revision number - quick question On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer bob.arc...@amsi.com wrote: On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. Hi Bob, we're still seeing the problem of unwanted touches of files and directories on new unmerged rev numbers, even after we reapply all merges for all previous already-merged at feature branch root level. We're getting concerned now, wondering if we misunderstood the explanations here. We're using SVN 1.6 Please check the poperties on one of the files. Tell me what the mergeinfo: is prior to your merge and after your merge. Up to this point we were talking about generalities, but we are getting down to specifics now. Also, 1.7 is much less chatty wrt where it adds merge info. BOb Thanks for your response. What does elided mean ? Elide simple means remove. We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit Great... if you always do your merges from your project root, you won't see this issue again.
RE: merge using same revision number - quick question
Hi All We have a revision that contains a few changed files on the trunk: r345 /usr/ext/a.java /usr/ext/b.java We like to merge this a branch working copy. Can we perform multiple merge svn with the same revision number ? We have a reason to do that; We know it doesnt make sense in this simple example. ie can we have 2 merge svn executions and still produce the same result as a simple merge execution. meaning svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java as opposed to svn merge -c 345 https://test.com/svn/root/src/usr/ext Thanks all. The resulting commit would probably be the same... although I expect the merge info would be applied to the files rather than the folder. Give your simple example a try in a test repo. BOb
RE: SVN Speed issue
I am handling SVN operations in my company. Today we find that SVN Speed is too much slow. VisualSVN Server : 2.5.7 Tortoise SVN : 1.6 Is that a question? Slow where? Client? 1.7 shows to be much faster for many client side operations. BOb
RE: SvnServe with Windows AD Authendication
Hi, I'm not a Windows guy and am not familiar with the services that Windows 2003 Server provides. Could you explain in more detail in what ways you want Subversion to integrate with it? Right now we are using svn internal authentication( passwd and svnserve.conf) Instead Of we are plan to use windows Active directory account for SVN. If you use SVN Edge it is very easy to use your windows domain logins with it. You just need to know your active directory server, OU names and such. We have ours set up this way. BOb From: Ryan Schmidt subversion-20...@ryandesign.com To: Krishnamoorthi Gopal krishnamoor...@vernal.is Cc: Mark Phippard markp...@gmail.com, Joseba Ercilla Olabarri joseba.erci...@gmail.com, users@subversion.apache.org Date: 03/27/2013 04:48 AM Subject: Re: SvnServe with Windows AD Authendication On Mar 26, 2013, at 15:49, Krishnamoorthi Gopal wrote: Right now i am having more than 250 repository with format what described below. I am going to put entry for each repository what you suggest. Is this advisable Subversion is flexible, so if this type of hierarchical arrangement makes the most sense to you, then you can certainly do that -- at the expense of having to maintain this configuration yourself in the Apache configuration file, instead of using the easier interface Subversion Edge makes available. Also i want to integrate svn with windows 2003 server.i hope you guide me . I'm not a Windows guy and am not familiar with the services that Windows 2003 Server provides. Could you explain in more detail in what ways you want Subversion to integrate with it? VERNALIS SYSTEMS EMAIL NOTICE - The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
RE: SvnServe with Windows AD Authendication
Hi, Yes i agree with your statement. But i am currently having SVN Server 1.5 without apache. Also my current repositories look like below svn://svnserver/svn/Projectname1/myrepo2 svn://svnserver/svn/Projectname1/myrepo3 svn://svnserver/svn/Projectname2/myrepo1 Each Project having two more repositories.How can i move these repository with same url setup into Edge. Please guide me to migrate my current setup into what you have. I have not known (or read about) anyone to get Active Directory working with svnserver. Supposedly it is possible... so someone else would have to help you. If you move to edge you would be using Apache and would be changing to the http:// protocol. So, your URL would change, but your clients can use a simple switch command to modify the URL of their existing working copies, we did the same thing. The main reason I moved to SVN Edge was to be able to use Active Directory (windows domain) logins so I wouldn't have to manage passwords. Now I just need to add/remove people from an Active Directory group that IT made me the admin of. Also, moving to edge would be an easy way to upgrade to 1.7.x, since that is the latest and greatest. You also should be able to set up SVN Edge without taking down your svnserve instance. Once you are satisfied that it is up and running and everything is working you can notify your users that they need to switch to the new url, and then you can stop the svnserve service. Regards Support Team. From: Bob Archer bob.arc...@amsi.com To: Krishnamoorthi Gopal krishnamoor...@vernal.is, Ryan Schmidt subversion- 20...@ryandesign.com Cc: Joseba Ercilla Olabarri joseba.erci...@gmail.com, Mark Phippard markp...@gmail.com, users@subversion.apache.org users@subversion.apache.org Date: 03/27/2013 10:13 PM Subject: RE: SvnServe with Windows AD Authendication Hi, I'm not a Windows guy and am not familiar with the services that Windows 2003 Server provides. Could you explain in more detail in what ways you want Subversion to integrate with it? Right now we are using svn internal authentication( passwd and svnserve.conf) Instead Of we are plan to use windows Active directory account for SVN. If you use SVN Edge it is very easy to use your windows domain logins with it. You just need to know your active directory server, OU names and such. We have ours set up this way. BOb From: Ryan Schmidt subversion-20...@ryandesign.com To: Krishnamoorthi Gopal krishnamoor...@vernal.is Cc: Mark Phippard markp...@gmail.com, Joseba Ercilla Olabarri joseba.erci...@gmail.com, users@subversion.apache.org Date: 03/27/2013 04:48 AM Subject: Re: SvnServe with Windows AD Authendication On Mar 26, 2013, at 15:49, Krishnamoorthi Gopal wrote: Right now i am having more than 250 repository with format what described below. I am going to put entry for each repository what you suggest. Is this advisable Subversion is flexible, so if this type of hierarchical arrangement makes the most sense to you, then you can certainly do that -- at the expense of having to maintain this configuration yourself in the Apache configuration file, instead of using the easier interface Subversion Edge makes available. Also i want to integrate svn with windows 2003 server.i hope you guide me . I'm not a Windows guy and am not familiar with the services that Windows 2003 Server provides. Could you explain in more detail in what ways you want Subversion to integrate with it? VERNALIS SYSTEMS EMAIL NOTICE - The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. VERNALIS SYSTEMS EMAIL NOTICE - The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
RE: Need to restructure repo folders: Problem: SVN COPY is recursive
Hi folks, We are changing our folder structure in the SVN repository and need to map content from old folders to the new folders. I was investigating the use of SVN COPY but the command is recursive, which leads to problems for us. For example, let's say our structure looks like: Original Folders \a \a\b \a\b\c And we are moving to a new structure where content from \a is copied to \d, \b to \e and \c also to \e: New Folders \d \d\e I can't do a SVN COPY of \b to \e because I would get: \d\e\c The only solution I can think of is to script a copy process on a file-by-file basis by first getting a list of files in folder \c, then SVN COPY each file individually into folder \e. Repeat for all folders. I can this in PERL but it seems like a long journey to get to the result. What am I missing? Is my approach flawed? That's pretty common because after all, a does contain folder b so when you copy a it is going to copy b. All you have to do is work bottom up copy \a\b\c \e copy \a\b \e Then of course you would have to remove \c from \e. Also, the svn copy command doesn't have advanced options like your shell does to copy files exclusive of folders and stuff. Hth, BOb Note that we want to keep the original structure in place as well as have the new one which is why I am playing with COPY instead of MOVE or SWITCH.
RE: Can't synchronize branch with trunk
Hi I've encountered a strange problem, hopefully someone can help me here. Below is a diagram of our repo -trunk--mod ABC-+ + | | | branch-copy WPB---Mods XYZ---+ 1. From trunk we created a copy to a new dev branch for workpackage-B. 2. Commits XYZ where made to branch WPB 3. In parallel, mods ABC where made to trunk 4. When trying to bring changes into WPB via merge, none of the changes are seen. They are basically ignored. I've tried cherry picking as well, but this synchronization merge isn't working. What could be wrong here? This is the output from my eclipse IDE, the same happens from the commandline: Operation Resource Path - --- Modified /home/kiren/Documents/workspace-QA/V2.1.0-work-package-B merge completed /home/kiren/Documents/workspace-QA/V2.1.0-work- package-B It's really difficult to tell here from the limited information. I assume Eclipse uses the svn libs rather than show you the command line. Can you run the command from the command line using svn.exe, show us your command and the output?
RE: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. You can keep the feature branch alive by doing a record only merge on the trunk of the revision which your integrate merge was committed as. BOb On Feb 22, 2013, at 7:22 PM, Matthew Pounsett m...@conundrum.com wrote: On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox /%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox /%3C20130207150922.GC28403%40ted.stsp.name%3E
RE: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. You can keep the feature branch alive by doing a record only merge on the trunk of the revision which your integrate merge was committed as. Sorry, this should say: You can keep the feature branch alive by doing a record only merge on the branch from trunk of the revision which your integrate merge was committed as. BOb BOb On Feb 22, 2013, at 7:22 PM, Matthew Pounsett m...@conundrum.com wrote: On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb ox /%3C01A9EBD6-CE2D-4565-833D- 2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb ox /%3C20130207150922.GC28403%40ted.stsp.name%3E
RE: Different commit message shown by SVN for the same commit
Dear all, I am not sure if this is a bug or I am missing something. But I just found a very unusual situation. Please refer to the screenshot below: Both parts in the above screenshot refer to the same revision in the same repository. The first part from the screenshot shows the commit log when I viewed log for trunk branch using TortoiseSVN. While in the second screenshot, I viewed the commit log for a particular file (/trunk/dev/App_Code/Profile/ProfileType.cs). Now what amazes me is how could the commit message be different. Can somebody give me some ideas :) What client are you using? Is that TortoiseSVN? If so, clear the log cache! BOb
RE: Tagging svn:externals
Some clients like TortoiseSVN have a feature that will pin the external to the revision you are copping when doing the tag. Otherwise, you have to do it manually before or after you create your tag. From: C M [mailto:cmanalys...@gmail.com] Sent: Wednesday, February 20, 2013 12:29 PM To: users@subversion.apache.org Subject: Tagging svn:externals It seems that SVN does not tag svn:externals. We have defined a structure such that child projects have link from a parent project. Parent project - child project_1 - child project_2 - child project_3 However, when you go to tag a release for a child, there's nothing in the /tags/Rel_X as I would normally expect. What's going on here? Amad
RE: Different commit message shown by SVN for the same commit
Dear all, I am not sure if this is a bug or I am missing something. But I just found a very unusual situation. Please refer to the screenshot below: Both parts in the above screenshot refer to the same revision in the same repository. The first part from the screenshot shows the commit log when I viewed log for trunk branch using TortoiseSVN. While in the second screenshot, I viewed the commit log for a particular file (/trunk/dev/App_Code/Profile/ProfileType.cs). Now what amazes me is how could the commit message be different. Can somebody give me some ideas :) What client are you using? Is that TortoiseSVN? If so, clear the log cache! I am using Tortoise SVN and cleared the entire log cache for all repos (and not just this one). Checked the commit log again from the 2 paths mentioned and it still shows different log messages as posted in my original message. Then I expect someone changed the revprop on either the branch or the trunk. BOb
RE: svn copy and history - quick question
Hi All We are SVN newbies here. We plan to do an svn copy (of a branch to another trunk). Does svn copy command copies all the history of the file and folder revisoins too ? Thanks The simple answer is... yes. BOb
RE: software distribution with subversion
I am faced with a problem where I need to distribute a directory containing about 60 GB worth of software on a Linux file server to about 100 systems. The software must be localized on those systems and not shared out over NFS. On a regular basis, software may be added or removed from the directory, and all the clients should update accordingly in the evening. During the update period, some client systems may be off. I think that Subversion would be a reasonable way to solve this problem which isn't quite the type of problem that rsync is intended to handle (because of the number of machines). However, for a variety of reasons, I don't want to run subversion on the actual file server. Instead, nightly, I'd like to rsync changes in the contents of the software directory on the file server to a software distribution server which would run its own svnserve. The clients would then connect up to the server nightly, and update themselves accordingly. Because of the versioning, if a client misses an update, it would be updated the next time around, even if its been off for a while. The inital update between the file server and the software update server would require rsyncing the whole 60 GB of software to a working directory, after which, to make subversion see this as a working directory, I would have to commit the entire directory, then check it back out. This process seems like a bit of a waste, but it's a one time process, and I don't really see any way around it. In the future, I would like to be able to rsync changes between the file server and the working directory on the software distribution server, which would including using --delete to ensure that software deleted from the file server is also deleted from the subversion working idrectory, and including the excluding of the .svn directory from the working copy. However, after the rsync happens, I now need to run a command that would update the repository with the state of the working directory. However, it's not exactly clear how this would work? Running an svn update isn't going to delete directories from the repository that were deleted from the working directory. I believe you need to use svn delete for this? Any ideas that anyone might be able to offer? I'm not on the list, so please ensure that you CC: me in any response. Thanks for your help! What you need to do could work. I assume this software in order to run can build built or whatever during your nightly update on each client? You keep saying rsyncing ... you wouldn't use that. You wouldn't use that of course, you would use the svn client binary. For you initial load... if the software is on the server where you will house your repository you can just import the data into the repository from that file... there is no need to send the data twice. In other words, you can have both a working copy and a repository on your central server. However, after the rsync happens, I now need to run a command that would update the repository with the state of the working directory. However, it's not exactly clear how this would work? Running an svn update svn update brings any changes in the repository to your working copy. svn commit does the opposite... it puts any changes in a working directory into the repository. Hth... That said, if this is actual software, wouldn't using one of the many package management tools available in Linux be a better fit? BOb
RE: Commit failed Error after upgrading 1.7.7
If you are using LDAP and the server is on Windows there is a bug in Apache 2.2.23 that can cause an HTTP 500 on the first authenticated request for a user. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=54140 Mark... that looks exactly what we are running into. Indeed we are using LDAP and running Edge on a Windows 2008 server. Are there any plans to release a new version of Edge that will resolve this issue. It is a minor annoyance but my users freak out when they see it. Thanks. On Nov 12, 2012, at 5:42 PM, Bob Archer bob.arc...@amsi.com wrote: On Mon, Nov 12, 2012 at 10:12 PM, Bob Archer bob.arc...@amsi.com wrote: I recently upgraded Subversion edge to 3.2.0-3352.100 which gave me Subversion 1.7.7. Since then every now and then when I commit I get the following error: Commit Commit failed (details follow): Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/svn/manage/!svn/me' Usually if I just retry the commit it works fine. Not a major issue, but a nuisance. Any ideas? Look for more details in the apache log file. Paul... I'm not sure which log to look in. Edge has an Error log, Subversion Log, Jetty Log, Console log. I looked in all of those from today, the error did occur for me this AM and don't seem to find a similar error to the one listed above. However, the jetty log does have quite a few errors listed. Does anyone have any more insite into this? I have looked in the logs and don't see anything wrt to the quoted error. It seems to be happening on every commit, and an then an immediate retry will be successful. Are these clients using serf on these connections? If so, try if switching to neon helps. I have no idea. I am using TortioseSVN 1.7.7, which I am pretty sure defaults to neon. There is no http-library setting in the config file. So, I think it is using neon. Also, I can't seem to figure out in Subversion Edge how to look at the configuration file. BOb
RE: Commit failed Error after upgrading 1.7.7
On Tue, Nov 13, 2012 at 10:22 AM, Bob Archer bob.arc...@amsi.com wrote: If you are using LDAP and the server is on Windows there is a bug in Apache 2.2.23 that can cause an HTTP 500 on the first authenticated request for a user. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=54140 Mark... that looks exactly what we are running into. Indeed we are using LDAP and running Edge on a Windows 2008 server. Are there any plans to release a new version of Edge that will resolve this issue. It is a minor annoyance but my users freak out when they see it. Yes. As you can see, the bug was only fixed yesterday. We need to confirm it still. Ok... no hurry, fix it right is better than fix it fast. I just wasn't sure if Edge releases were done even if there wasn't a new svn release. Hence my query. BOb
RE: Commit failed Error after upgrading 1.7.7
I recently upgraded Subversion edge to 3.2.0-3352.100 which gave me Subversion 1.7.7. Since then every now and then when I commit I get the following error: Commit Commit failed (details follow): Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/svn/manage/!svn/me' Usually if I just retry the commit it works fine. Not a major issue, but a nuisance. Any ideas? Look for more details in the apache log file. Paul... I'm not sure which log to look in. Edge has an Error log, Subversion Log, Jetty Log, Console log. I looked in all of those from today, the error did occur for me this AM and don't seem to find a similar error to the one listed above. However, the jetty log does have quite a few errors listed. Does anyone have any more insite into this? I have looked in the logs and don't see anything wrt to the quoted error. It seems to be happening on every commit, and an then an immediate retry will be successful. Thanks, Bob
RE: Commit failed Error after upgrading 1.7.7
On Mon, Nov 12, 2012 at 10:12 PM, Bob Archer bob.arc...@amsi.com wrote: I recently upgraded Subversion edge to 3.2.0-3352.100 which gave me Subversion 1.7.7. Since then every now and then when I commit I get the following error: Commit Commit failed (details follow): Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/svn/manage/!svn/me' Usually if I just retry the commit it works fine. Not a major issue, but a nuisance. Any ideas? Look for more details in the apache log file. Paul... I'm not sure which log to look in. Edge has an Error log, Subversion Log, Jetty Log, Console log. I looked in all of those from today, the error did occur for me this AM and don't seem to find a similar error to the one listed above. However, the jetty log does have quite a few errors listed. Does anyone have any more insite into this? I have looked in the logs and don't see anything wrt to the quoted error. It seems to be happening on every commit, and an then an immediate retry will be successful. Are these clients using serf on these connections? If so, try if switching to neon helps. I have no idea. I am using TortioseSVN 1.7.7, which I am pretty sure defaults to neon. There is no http-library setting in the config file. So, I think it is using neon. Also, I can't seem to figure out in Subversion Edge how to look at the configuration file. BOb
