How to undo accidental 'pinning' of sub-directories?
A colleague new to Subversion has a part of a project spread across a number of sibling directories. He had been making some significant changes and didn't want to “risk” doing a ‘svn update’ on the top level directory, instead manually doing updates on the siblings of the main directory he was working in. These piecemeal updates happened across several days, spanning several revisions. When we came to make a branch for his work as ‘svn switch’ to it (at his top-level), we found that most of the sibling directories were still linked to their positions in trunk. I'm guessing that the multiple individual updates ‘pinned’ the siblings to the respective revision of the update as if a a ‘svn switch’ had been done. Given that where we ended up was a mess of our (well, his) own devising, I'm left wondering what the best recovery would have been? I had to manually ‘svn-switch’ the sibling dirs., sort out the commit, then clear out the whole lot with a fresh checkout (well, I actually set the root depth to “only” followed by “infinity” to reset it). In general, if you have a hierarchy that may have had some switches (etc.) applied at arbitrary locations within it, is there a way to enforce an update at the top level that undoes the switches (without blowing it all away and re-creating the working copy, as there may be local changes)? -- [n...@fnx ~]# rm -f .signature [n...@fnx ~]# ls -l .signature ls: .signature: No such file or directory [n...@fnx ~]# exit
Re: SSL Error
Thanks for your help Stefan. I tried your suggestions (using the 1.6.11 svn CLI on windows and specifying the --non-interactive --trust-server-cert options), but neither worked. Fortunately, when I tried the latest svn CLI (1.6.15), it functioned just like the linux CLI (asking me to accept the certificate validation error) and then the operation succeeded. The problem still exists in the latest version of TortoiseSVN (which claims to be linked against svn 1.6.15), but I will take that up w/ the TortoiseSVN folks. Thanks again! Nick On Thu, 2010-12-16 at 19:17 +0100, Stefan Sperling wrote: > On Thu, Dec 16, 2010 at 09:34:05AM -0500, Nick wrote: > > Hi all, > > > > At some point in the last year I stopped being able to access my SVN > > repository remotely via https using the SVN CLI and TortoiseSVN on > > Windows. Unfortunately since I hadn't used svn on my windows machine > > for a long time (many months), I cannot give a more accurate timeframe. > > > > The error I get when I try to checkout via the svn.exe CLI is (I masked > > my domain & path): > > > > c:\ svn.exe checkout https://.com/ > > svn: OPTIONS of 'https://.com/': > > SSL negotiation failed: SSL error code -1/1/336032856 > > (https://.com) > > > > My svn server is running via Apache. Client and server are both version > > is 1.6.13. The web server is using openssl 1.0.0c. > > > > I am able to checkout and access my repository fine from another linux > > client via the same domain name. And on Windows, I can browse the > > repository with Firefox. But in both of these cases, the linux svn CLI > > and Firefox both prompt that the SSL certificate is risky/invalid for a > > couple reasons: it's self-signed and reflects a different host than the > > domain I'm actually connecting to. This is because the SSL certificate > > reflects my server's internal hostname (for reasons I won't get into > > here) rather than the public domain name. So for both the linux client > > and Firefox I had to explicitly accept this discrepancy. > > > > The linux svn CLI yields this: > > # svn checkout https://.com/ > > Error validating server certificate for 'https://.com:443': > > - The certificate is not issued by a trusted authority. Use the > >fingerprint to validate the certificate manually! > > - The certificate hostname does not match. > > Certificate information: > > - Hostname: nimble > > - Valid: from Tue, 16 Mar 2010 02:14:36 GMT until Fri, 13 Mar 2020 > > 02:14:36 GMT > > - Issuer: > > - Fingerprint: > > 50:2b:50:a5:75:61:ae:f2:a0:d2:44:4f:12:6b:d3:6e:f8:c5:4b:12 > > (R)eject, accept (t)emporarily or accept (p)ermanently? > > > > And if I accept this validation error, everything works properly. > > > > So I wonder if the error I'm getting from the Windows svn.exe is related > > to my risky/invalid certificate. So one question I have is: how do I > > instruct svn to accept the certificate even though it's not completely > > valid? > > Maybe it is related to this change released in June 2010 in 1.6.12: > >* check for server certificate revocation on Windows (r898048) > > > r898048 | rhuijben | 2010-01-11 21:13:13 +0100 (Mon, 11 Jan 2010) | 10 lines > > Extend the (Windows only) ssl server certificate validation via cryptoapi > with a certificate revocation check. Also use a proper certificate chain > verification, before trusting the certificate as valid instead of just > parsing the certificate status ourselves. > > * subversion/libsvn_subr/win32_crypto.c > (windows_validate_certificate): Add revocation check flag and verify the > certificate chain as a ssl chain instead of reading the status of the > leave certificate ourselves. > > > > Does Windows perhaps believe that the certificate has been revoked > for some reason? I cannot think of any other reason. > > Does it work if you try versions older than 1.6.12? > > > Any other suggestions? > > Try this: > svn checkout --non-interactive --trust-server-cert > https://.com/ > > Stefan
Problem with My SVN Server
Hi This is Santhosh Kumar from Bangalore, I have a chat with Mr. C. Michael Pilato regarding a problem with My SVN Server, he suggested me to contact in this mail id. I am expecting a positive output from your group. I have a svn server, I was using it for the past 6-8 months without any problem. The problem is that, I am not able to check out a file from the svn server system. But the same file can be checked out from any other linux box. >From the server I wanted to checkout the same file for some script. It is a tar.bz2 file The error is svn: Can't open file 'flse/.svn/tmp/text-base/pgms.tar.bz2.svn-base': Permission denied. But the same file I am able to do a check out from another linux box. I am running the checkout as root user- having all permission. Request you to assist me with this. with hopes.. Santhosh Kumar K V
Re: Archiving Projects (End-Of-Life)
> On Wed, Dec 15, 2010 at 8:50 AM, Andy Levy wrote: > > If you just need to set the whole directory read-only unilaterally, > you don't need a pre-commit hook; just use the built-in path-based > authorization. On Thu, Dec 16, 2010 at 12:57 AM, Nico Kadel-Garcia wrote: > Well, no, you don't *need* to do it that way. But each access method > has its own access control, whether svn or svn+ssh, file based, or > http/https. Rather than exerting cleverness, simply disabling all > writes in a clean and easily restored fashion, and one that is more > certain to be replicated by an svnadmin hotcopy, seems quite > reasonable. There are advantages to path based authorization and using a pre-commit hook. One advantage with path-based authorization is that you can create read (or more importantly "non-read" access). You can't do that with a hook. Path based authorization also uses fewer resources than a pre-commit hook. With path based authorization, the Subversion server can do the authorization as it does whatever processing it needs. With a pre-commit hook, the server has to run another program. Most pre-commit hooks run on an "O-squared" algorithm. Each file must be tested against each permission. If you are committing a few files, and you only have a few rules, the pre-commit hook is barely noticeable. But if you're committing thousands of files and checking them against thousands of arcane permissioning rules, your pre-commit hook execution time might start hitting the nuisance zone. However, a pre-commit hook has certain advantages. With a path based authorization and Apache, you have to bounce the server every time you change permissions. This can be difficult to do. Plus, changing the permissions might require approval of other individuals and departments since you're changing the Apache configuration. With a pre-commit hook, changing permissions is instantaneous and requires simply modifying the pre-commit hook configuration file. Something most Subversion admins can do on their own. Also a pre-commit hook puts the authorization in the Subversion repository directory where it gets backed up on a regular basis. If your Subversion server crashes and has to be rebuilt, you might not remember a highly detailed path-based authorization, but your pre-commit hook authorization list is safely backed up. Also, a pre-commit hook can do "add-only" authorization. This allows users to create a tag, but not modify the tag once it is created. A similar thing could be done with this "obsolete" directory: Technical leads can add branches and maybe projects into the "obsolete" directory, but no one can modify a file once it is there. My general rule of thumb is to setup gross permissions with the path based authorization -- especially those that depend upon no read access. For example, only people in the LDAP developer group can access our Subversion server, and only people in this department can modify their directory tree , but other developers will be able to read it. >From there, I use a pre-commit hook to fine tune it. For example, locking a branch or tag to prevent its modification. Or allowing only a few select users the ability to modify a release branch. This is mainly to prevent whoops scenarios. For example, a developer forgetting to "svn switch" from the branch to the trunk before they continue their development work. -- David Weintraub qazw...@gmail.com
Re: SSL Error
Thanks for this problem description and resolution. I was using an older version of TSVN and was asked (told) to upgrade to the latest. Now I can't even log into the server. From the description below, I think I have the same problem. :-( I will take this up with the server admionistrator, as he is the one who told me to upgrade my TSVN copy. I used TSVN a little bit a year ago, but other than that, all my SVN use has been cle from Linux. > Thanks for your help Stefan. > > I tried your suggestions (using the 1.6.11 svn CLI on windows and > specifying the --non-interactive --trust-server-cert options), but > neither worked. > > Fortunately, when I tried the latest svn CLI (1.6.15), it functioned > just like the linux CLI (asking me to accept the certificate validation > error) and then the operation succeeded. > > The problem still exists in the latest version of TortoiseSVN (which > claims to be linked against svn 1.6.15), but I will take that up w/ the > TortoiseSVN folks. > > Thanks again! > > Nick > > > On Thu, 2010-12-16 at 19:17 +0100, Stefan Sperling wrote: > >> On Thu, Dec 16, 2010 at 09:34:05AM -0500, Nick wrote: >> > Hi all, >> > >> > At some point in the last year I stopped being able to access my SVN >> > repository remotely via https using the SVN CLI and TortoiseSVN on >> > Windows. Unfortunately since I hadn't used svn on my windows machine >> > for a long time (many months), I cannot give a more accurate >> timeframe. >> > >> > The error I get when I try to checkout via the svn.exe CLI is (I >> masked >> > my domain & path): >> > >> > c:\ svn.exe checkout https://.com/ >> > svn: OPTIONS of 'https://.com/': >> > SSL negotiation failed: SSL error code -1/1/336032856 >> > (https://.com) >> > >> > My svn server is running via Apache. Client and server are both >> version >> > is 1.6.13. The web server is using openssl 1.0.0c. >> > >> > I am able to checkout and access my repository fine from another linux >> > client via the same domain name. And on Windows, I can browse the >> > repository with Firefox. But in both of these cases, the linux svn >> CLI >> > and Firefox both prompt that the SSL certificate is risky/invalid for >> a >> > couple reasons: it's self-signed and reflects a different host than >> the >> > domain I'm actually connecting to. This is because the SSL >> certificate >> > reflects my server's internal hostname (for reasons I won't get into >> > here) rather than the public domain name. So for both the linux >> client >> > and Firefox I had to explicitly accept this discrepancy. >> > >> > The linux svn CLI yields this: >> > # svn checkout https://.com/ >> > Error validating server certificate for 'https://.com:443': >> > - The certificate is not issued by a trusted authority. Use the >> >fingerprint to validate the certificate manually! >> > - The certificate hostname does not match. >> > Certificate information: >> > - Hostname: nimble >> > - Valid: from Tue, 16 Mar 2010 02:14:36 GMT until Fri, 13 Mar 2020 >> > 02:14:36 GMT >> > - Issuer: >> > - Fingerprint: >> > 50:2b:50:a5:75:61:ae:f2:a0:d2:44:4f:12:6b:d3:6e:f8:c5:4b:12 >> > (R)eject, accept (t)emporarily or accept (p)ermanently? >> > >> > And if I accept this validation error, everything works properly. >> > >> > So I wonder if the error I'm getting from the Windows svn.exe is >> related >> > to my risky/invalid certificate. So one question I have is: how do I >> > instruct svn to accept the certificate even though it's not completely >> > valid? >> >> Maybe it is related to this change released in June 2010 in 1.6.12: >> >>* check for server certificate revocation on Windows (r898048) >> >> >> r898048 | rhuijben | 2010-01-11 21:13:13 +0100 (Mon, 11 Jan 2010) | 10 >> lines >> >> Extend the (Windows only) ssl server certificate validation via >> cryptoapi >> with a certificate revocation check. Also use a proper certificate chain >> verification, before trusting the certificate as valid instead of just >> parsing the certificate status ourselves. >> >> * subversion/libsvn_subr/win32_crypto.c >> (windows_validate_certificate): Add revocation check flag and verify >> the >> certificate chain as a ssl chain instead of reading the status of >> the >> leave certificate ourselves. >> >> >> >> Does Windows perhaps believe that the certificate has been revoked >> for some reason? I cannot think of any other reason. >> >> Does it work if you try versions older than 1.6.12? >> >> > Any other suggestions? >> >> Try this: >> svn checkout --non-interactive --trust-server-cert >> https://.com/ >> >> Stefan >
branch creation - merge not working?
Using SilkSVN as my DOS client (actually using TortoiseSVN, but for mailing lists 'command line copy and paste' is easier than 'image linking'), I'm having problems with branch creation(merge) when evaluating Subversion for our workflow. The typical workflow is (in Subversion verbage): Release planning: Software Lead creates an integration branch, merging from the trunk Development: Software Engineer creates a work branch, merging from integration branch Software Engineer performs work in work branch Software Engineer re-integrates work branch back into the integration branch (repeat x times for y engineers) Release delivery: Software Lead locks down integration branch (permissions become read only) Software Lead re-integrates integration branch back into trunk Release Engineer tags trunk A project layout is typically like this: TestProject/ __trunk/ __tags/ release1/ __branches/ integration/ __release1/ __release2/ __majorFeature1/ softwareTeamMember1/ __branchName1/ __branchName2/ softwareTeamMember2/ __branchName1/ I'm having a problem with this step of the process: Software Engineer creates a work branch, merging from integration branch I was able to merge trunk into integration/release2/, and the expected files are created. However, when I merge integration/release2/ into softwareTeamMember1/branchName1/, none of the expected files are created. However, when I merge trunk into softwareTeamMember1/branchName1/, the expected files are created. Why?? And how do I get the workflow that we are used to operating under with Subversion? C:\TestProject\branches\integration\release2>svn list .project flash-image.txt installation-doc.txt sim-exe.txt user-guide-doc.txt C:\TestProject\branches\software1\issue34>svn list C:\TestProject\branches\software1\issue34>svn merge https://localhost/svn/TestProject/branches/integration/relea...@head . C:\TestProject\branches\software1\issue34>dir Volume in drive C has no label. Volume Serial Number is B0F5-5D37 Directory of C:\TestProject\branches\software1\issue34 12/17/2010 09:22 AM . 12/17/2010 09:22 AM .. 0 File(s) 0 bytes 2 Dir(s) 218,571,730,944 bytes free C:\TestProject\branches\software1\issue34>svn propget svn:mergeinfo . /branches/integration/release2:46 C:\TestProject\branches\software1\issue34>svn merge https://localhost/svn/TestProject/tr...@head . --- Merging r2 through r45 into '.': Ainstallation-doc.txt A.project Asim-exe.txt Auser-guide-doc.txt Aflash-image.txt U . C:\TestProject\branches\software1\issue34>svn propget svn:mergeinfo . /branches/integration/release1:7-35 /branches/integration/release2:46 /branches/software1/issue12:23-31 /trunk:2-46
Re: branch creation - merge not working?
Wow! Were you once a ClearCase user? This is exactly how ClearCase or a distributed version control system would work. Subversion merges are problematic. In fact, I know many sites that simply refuse to merge stuff. Instead, they just manually apply the changes. You have to know when to use and not to use the --reintergrate parameter. That said, when you merge from branch "A" to branch "B" and then merge branch "B" to Branch "C", new files are not always created because of the way Subversion tracks changes. What you need to do is merge Branch "A" to branch "B" and then merge Branch "A" to branch "C". What you might want to understand is how Subversion's branching scheme was designed to work. Subversion is built to borrow the CVS workflow. It works somewhat like this: * All users work on a single branch. In many sites, this is "trunk". * When you are nearing release time, many sites will branch from "trunk" to a "release branch". This way, one group of users can continue working on new features of your project on trunk while another group of users can work on getting the branch ready for release. If there is merging, it is usually bug fixes that were discovered on the branch, implemented in the trunk, then merged to the release branch. Subversion handles this type of merging with aplomb. You can merge your changes the other way, but you'll need to use that --reintegrate command line switch. * When the software is released, the tagging is done, the release branch (not the trunk) is copied to the tags directory. The reason I said it sounds like your a ClearCase user is that you describe more or less the way it is done via ClearCase UCM and how most sites implement base ClearCase. I've joked that ClearCase combines all the problems of a distributed version control system (developers working in their merry ol' world with lots of patching/merging going on), and all the disadvantages of a centralized version control system (heavy network traffic, single point of failure of the repository, etc.). For example, why do you merge everything back to trunk? It contains nothing. No one does any work on it. What does trunk represent to you? The latest release? That's what the tags directory is for. But, I've seen so many sites do the same thing. The answer they give is always the same: "This way trunk only has released code on it." But, no one can explain to me how is this important. I blame PowerPoint. Someone comes up with some goofy branching scheme because it looks good in PowerPoint, and then realizes that trunk isn't doing anything. So, they draw one arrow back from the branch to trunk. All the arrows line up nice and neat and all the little boxes are in order. I was trained as a CM on ClearCase, and I bought the idea of development and integration branches because that's how it is suppose to be done! Sure, I spent a ton of time running around and pestering developers to merge their work back into the "integration branch", and we always had big merge conflicts and someone always delivers a few gigabytes of changes in the last minute, but that's how development is suppose to work. Right? When I started working for a shop with about 4 dozen developers spread out all over the world using CVS, I was shocked. There's no way this would work. Everyone using trunk? What about developer branches? How can a developer make changes if other developers are changing trunk all the time? When I saw how the whole process worked, I was in an immediate funk because I suddenly realized that this group really didn't need me running around any more and pestering them. What is a CM suppose to do besides be a pain in the butt? It took me a while to learn that if I'm not spending 8 hours each day pestering developers and trying to fix broken merges, I can do all the other CM things I never had time to do. Since then, I've been an advocate of the Benign Neglect school of CM management: Do things the easy way. The simpler the better. Why branch? Be happy! -- David Weintraub qazw...@gmail.com
Re: Subversion 1.6.15 Released
I'm finally happy to announce my release of Subversion 1.6.15 Win32 binaries and installer. Sorry about the late release but I had done some work on my house in the last weeks. They are available on SourceForge: http://sourceforge.net/projects/win32svn/ (preferred) and also at my website:http://alagazam.net Release notes for the 1.6.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.6.html You can find the list of changes between 1.6.15 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.6.15/CHANGES Questions, comments, and bug reports to us...@subversion.apache.org. Merry X-mas to the whole SVN community David Darj http://alagazam.net
Re: Subversion 1.6.15 Released
Any idea why TSVN 1.6.12 Build 20536 2010/11/24 claims to be using SVN 1.6.15 before it was released? > I'm finally happy to announce my release of Subversion 1.6.15 Win32 > binaries and installer. > Sorry about the late release but I had done some work on my house in the > last weeks. > > They are available on SourceForge: > http://sourceforge.net/projects/win32svn/ (preferred) > and also at my website:http://alagazam.net > > > Release notes for the 1.6.x release series may be found at: > > http://subversion.apache.org/docs/release-notes/1.6.html > > You can find the list of changes between 1.6.15 and earlier versions at: > > http://svn.apache.org/repos/asf/subversion/tags/1.6.15/CHANGES > > Questions, comments, and bug reports to us...@subversion.apache.org. > > > Merry X-mas to the whole SVN community > > David Darj > http://alagazam.net > > > > >
Re: log -g regression in 1.6.15?
Stefan Sperling wrote on 12/16/2010 03:11:03 PM: > On Thu, Dec 16, 2010 at 02:50:27PM -0600, kmra...@rockwellcollins.com wrote: > > I have observed some regressions with > > > > log -v -g --xml http://server/repo/path > > > > output in 1.6.15 that were not present in 1.6.13. I see a lot of -g > > changes > > in this new version. > > Hi Kevin, > > There are three -g changes: > >* fix server-side memory leaks triggered by 'blame -g' (r1032808) >* allow 'log -g' to continue in the face of invalid mergeinfo (r1028108) >* fix abort in 'svn blame -g' (issue #3666) > > Can you try to back out each of them to see if the problem persists? It will probably be a bit before I get a build environment setup to test. > > I'll try and narrow down a test case, > > That would be great. No success yet, and I realize it is pretty hard to fix what we don't know the cause... Kevin R.
Re: Subversion 1.6.15 Released
On Fri, Dec 17, 2010 at 16:42, wrote: > Any idea why TSVN 1.6.12 Build 20536 2010/11/24 claims to be using SVN > 1.6.15 before it was released? http://tortoisesvn.net/status.html says it was released on 11/27/2010, not 11/24/2010. But regardless, the question would be more appropriate on the TSVN mailing list, not spammed to the SVN Dev & Announce lists.
Re: Subversion 1.6.15 Released
On Fri, Dec 17, 2010 at 4:42 PM, wrote: > Any idea why TSVN 1.6.12 Build 20536 2010/11/24 claims to be using SVN > 1.6.15 before it was released? Subversion 1.6.15 was released several weeks ago. David is just one person of many that creates a binary version and he is simply announcing availability of his binaries. TortoiseSVN does not release until we have officially released the source. BTW, David is there really any reason to broadcast your release in these forums? CollabNet has never done that (and would not want to see us start). While I think the info is somewhat useful in general it would get ugly if everyone that produced binaries announced it on all the lists every time. You can announce it on sf.net and users can subscribe to lists or RSS feeds there if they want to be updated on releases. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Subversion 1.6.15 Released
I am not subscribed to the dev or announce lists, and the header says this is the users list, and my installed TSVN's "about" shows 11/24. I cannot imagine how this would have ended up on dev or announce. :-\ > On Fri, Dec 17, 2010 at 16:42, wrote: >> Any idea why TSVN 1.6.12 Build 20536 2010/11/24 claims to be using SVN >> 1.6.15 before it was released? > > http://tortoisesvn.net/status.html says it was released on 11/27/2010, > not 11/24/2010. > > But regardless, the question would be more appropriate on the TSVN > mailing list, not spammed to the SVN Dev & Announce lists. >
Re: Subversion 1.6.15 Released
On Fri, Dec 17, 2010 at 04:42:16PM -0500, r...@elilabs.com wrote: > Any idea why TSVN 1.6.12 Build 20536 2010/11/24 claims to be using SVN > 1.6.15 before it was released? TortoiseSVN doesn't follow skips in version numbers that occasionally happen between Subversion releases. E.g. the entry for 1.6.14 in https://svn.apache.org/repos/asf/subversion/trunk/CHANGES reads as follows: Version 1.6.14 (Not released, see changes for 1.6.15.) This means Subversion 1.6.14 did not pass pre-release testing and wasn't made publicly available. Because TortoiseSVN releases don't use the same version numbers as the Subversion releases they're based on, TortoiseSVN users need to look at the "based on Subversion release X" number to find out which version of Subversion release they are using. (In case this relationship is unclear: TortoiseSVN, like virtually every other Subversion client out there, is a wrapper around the Subversion core libraries.) Even if TortoiseSVN did skip release numbers skipped by Subversion, release numbers could get out of sync if TortoiseSVN issued a release to fix a bug that's present in TortoiseSVN but not in Subversion. It's unlikely that we're ever going to see version numbers for both the Subversion core and TortoiseSVN increase in lock-step. Stefan
RE: branch creation - merge not working?
I appreciate your zealot for a different workflow. However, I've found a substantial improvement in productivity and tracking by adopting the workflow we use now over the workflow you suggest - we did start with an almost identical workflow. Granted, the small commercial and open source environment (most users of Subversion?) is very different from our work environment (aerospace - we're not one of the big 3). However, I don't wish to pollute the mailing list with pedantic squabbles over which is 'better' and will leave it at this: our needs are just different. For those that have run into this same problem: it took me most of the day to realize the small (but important!) mistake that I had made: 'svn merge' is not the way to create a branch, 'svn copy' is the way to create a branch. C:\TestProject\branches\software1\issue34>svn MERGE https://localhost/svn/TestProject/branches/integration/relea...@head . should have been: C:\TestProject\branches\software1\issue34>svn COPY https://localhost/svn/TestProject/branches/integration/relea...@head . Once I switched to using 'svn copy' for branch creation, our workflow works just fine in Subversion 1.6 and this product appears to meet our needs. This revision graph shows a that a branch-heavy works just fine: http://img801.imageshack.us/i/65330015.jpg Thanks, Brian Date: Fri, 17 Dec 2010 13:39:01 -0500 Subject: Re: branch creation - merge not working? From: qazw...@gmail.com To: linda...@hotmail.com CC: users@subversion.apache.org Wow! Were you once a ClearCase user? This is exactly how ClearCase or a distributed version control system would work. Subversion merges are problematic. In fact, I know many sites that simply refuse to merge stuff. Instead, they just manually apply the changes. You have to know when to use and not to use the --reintergrate parameter. That said, when you merge from branch "A" to branch "B" and then merge branch "B" to Branch "C", new files are not always created because of the way Subversion tracks changes. What you need to do is merge Branch "A" to branch "B" and then merge Branch "A" to branch "C". What you might want to understand is how Subversion's branching scheme was designed to work. Subversion is built to borrow the CVS workflow. It works somewhat like this: * All users work on a single branch. In many sites, this is "trunk". * When you are nearing release time, many sites will branch from "trunk" to a "release branch". This way, one group of users can continue working on new features of your project on trunk while another group of users can work on getting the branch ready for release. If there is merging, it is usually bug fixes that were discovered on the branch, implemented in the trunk, then merged to the release branch. Subversion handles this type of merging with aplomb. You can merge your changes the other way, but you'll need to use that --reintegrate command line switch. * When the software is released, the tagging is done, the release branch (not the trunk) is copied to the tags directory. The reason I said it sounds like your a ClearCase user is that you describe more or less the way it is done via ClearCase UCM and how most sites implement base ClearCase. I've joked that ClearCase combines all the problems of a distributed version control system (developers working in their merry ol' world with lots of patching/merging going on), and all the disadvantages of a centralized version control system (heavy network traffic, single point of failure of the repository, etc.). For example, why do you merge everything back to trunk? It contains nothing. No one does any work on it. What does trunk represent to you? The latest release? That's what the tags directory is for. But, I've seen so many sites do the same thing. The answer they give is always the same: "This way trunk only has released code on it." But, no one can explain to me how is this important. I blame PowerPoint. Someone comes up with some goofy branching scheme because it looks good in PowerPoint, and then realizes that trunk isn't doing anything. So, they draw one arrow back from the branch to trunk. All the arrows line up nice and neat and all the little boxes are in order. I was trained as a CM on ClearCase, and I bought the idea of development and integration branches because that's how it is suppose to be done! Sure, I spent a ton of time running around and pestering developers to merge their work back into the "integration branch", and we always had big merge conflicts and someone always delivers a few gigabytes of changes in the last minute, but that's how development is suppose to work. Right? When I started working for a shop with about 4 dozen developers spread out all over the world using CVS, I was shocked. There's no way this would work. Everyone using trunk? What about developer branches? How can a developer make changes if other developers are changing trunk all the time? Whe
kml files
Hello, I'm trying to get a kml file to launch google earth from a web page under subversion control. When it loads the page you only see the code from the kml file not google earth. http://crsvn/vpdb_library/branches/library_documents/RC Library - Military EPX AF 3-17-10.kml"> Help Dudley
Re: Subversion 1.6.15 Released
On Fri, Dec 17, 2010 at 05:07:44PM -0500, r...@elilabs.com wrote: > I am not subscribed to the dev or announce lists, and the header says this > is the users list, and my installed TSVN's "about" shows 11/24. I cannot > imagine how this would have ended up on dev or announce. :-\ Ah, I misunderstood your question because I was only looking at version numbers, not the date stamp. The date in the binaries might be off if the TortoiseSVN team produced binaries based on pre-release Subversion source code that went into the pre-release testing phase. If the test phase was successful the Subversion project releases the source officially, and TortoiseSVN binaries built a few days eariler are now known good and can be released, too. Stefan
Re: Subversion 1.6.15 Released
On 2010-12-17 22:58, Mark Phippard wrote: On Fri, Dec 17, 2010 at 4:42 PM, wrote: Any idea why TSVN 1.6.12 Build 20536 2010/11/24 claims to be using SVN 1.6.15 before it was released? Subversion 1.6.15 was released several weeks ago. David is just one person of many that creates a binary version and he is simply announcing availability of his binaries. TortoiseSVN does not release until we have officially released the source. BTW, David is there really any reason to broadcast your release in these forums? CollabNet has never done that (and would not want to see us start). While I think the info is somewhat useful in general it would get ugly if everyone that produced binaries announced it on all the lists every time. You can announce it on sf.net and users can subscribe to lists or RSS feeds there if they want to be updated on releases. I just keep up the work where DJ Heap (and Troy Simpson) left off building and announcing these binaries. If it's not appropiate to announce it here I will stop. Anyway announcment on my Win32 build of Subversion will be announced at the sf page at https://sourceforge.net/projects/win32svn/ where a RSS feed is also available. /David
Re: kml files
Been a while since I did kml, but here is a URL that works: http://maps.google.com/maps?q=http://www.elilabs.com/~myword/temp/gaz_23084.kml&t=k Note that you must specify the google domain name, and pass your kml file as a cgi parameter to it. > Hello, > > I'm trying to get a kml file to launch google earth from a web page under > subversion control. > > When it loads the page you only see the code from the kml file not google > earth. > > http://crsvn/vpdb_library/branches/library_documents/RC Library - > Military EPX AF 3-17-10.kml"> > > Help > Dudley
Re: kml files
Check to see what mime-type the file svn:mime-type property is set to. I don't have a complete answer for you but I suspect it will involve using the svn propset command to chang/set the svn:mime-type to the correct type to allow the browser to interpret the file data. Something like: svn propset svn:mime-type 'text/html' FILENAME where FILENAME is the file you want to have displayed or processed and "text/html" is replaced with the correct mime-type. ~~R dbwic...@rockwellcollins.com wrote the following on 12/17/2010 02:12 PM: Hello, I'm trying to get a kml file to launch google earth from a web page under subversion control. When it loads the page you only see the code from the kml file not google earth. http://crsvn/vpdb_library/branches/library_documents/RC Library - Military EPX AF 3-17-10.kml"> Help Dudley
Re: Subversion 1.6.15 Released
On Fri, Dec 17, 2010 at 5:46 PM, David Darj wrote: > I just keep up the work where DJ Heap (and Troy Simpson) left off building > and announcing these binaries. > If it's not appropiate to announce it here I will stop. David, I do not want to give you the impression that I think you are doing something wrong. Like I said, there is some value and general interest in letting people know. The issue is that you are just one of many people producing binaries and for the most part I do not think anyone else is announcing each release on these lists. I would personally not want to see everyone that makes binaries do this as I think it would get very "spammy" whenever there is a new SVN release. There was also this instance here where a user apparently thought you were announcing the SVN release, and not just your binaries. So I guess there is some possibility for confusion. If you want to make an announcement over here, I would suggest using the announce@ list only, but that is just one person's suggestion/opinion. Personally, I think when the SVN project issue a release announcement people just go to their preferred location to get the binaries and do not wait or look for a separate announcement. -- Thanks Mark Phippard http://markphip.blogspot.com/
