Re: Change prevprops in pre-commit
On 09/08/2014 09:26 AM, Philip Martin wrote: Sergey Azarkevich azarkev...@gmail.com writes: I see in pre-commit hook template that changing revisions properties in transaction are allowed. But I can't find way for it (I want change svn:author to more readable). Is here way for this with svn, svnadmin, svnlook ... or other standard tool? Or I should use Subversion API and write simple tool? I think we should provide command line support for setting txnprops. The code is simple enough, the iterface is a bit harder. There was was some debate on IRC as to whether it should be svnlook propset -t txn or svnadmin settxnprop -t txn Why not just 'svnadmin setrevprop -t txn' ? New option, but not a new subcommand. I don't think it all that important to distinguish between transaction props and revision props once we get outside our API space and into user command space. Our users understand revision props as properties on revisions, and transactions as revisions-to-be ... the rest is fairly trivial inference. (And yes, 'svnlook' should be kept read-only.) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development
Re: Feature Request: revprop for svn:client Was: Tree conflict on Fresh checkout
On 06/21/2013 02:22 PM, James Hanley wrote: In hind site, if there was a revprop that included the version of the client, if an artifact issue (such as this) is discovered in the repository, this rev-prop can succinctly tell the administrator which version of the client introduced the issue for reporting back to support. It could also allow (via pre-commit hook script) the ability to blacklist versions of the client that have issues. In Subversion 1.8, I added code to the server and client layers to propagate the client program's user agent string and version number of the Subversion libraries in use. This information gets set as an ephemeral transaction property on the commit transaction, which is to say that it lives in a regular transaction property, but that property is automatically deleted from the transaction before the commit is finalized. The cool this is that admins can use their pre-commit hook scripts to copy any ephemeral transaction property that they want to persist post-commit to another property name (that *won't* get auto-removed). See http://subversion.apache.org/docs/release-notes/1.8.html#ephemeral-txnprops for details. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: user issues on svnrdump
On 06/19/2013 12:29 AM, Bo Chen wrote: It seens that the first dump will automatically strip-off trunk, but the second dump does not strip off dump. My subversion version is 1.7.5. What happen? Any suggestion for me to solve it? I believe you are describing issue #4101 http://subversion.tigris.org/issues/show_bug.cgi?id=4101 I fixed this bug some time ago, and the fix was released in Subversion 1.8.0. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Remove from lists, please
On 06/18/2013 08:17 AM, Stephen Shaffer wrote: Please remover any and all instances of the following email from any Subversion list(s): sshaf...@microdataware.com mailto:sshaf...@microdataware.com stephenashaf...@gmail.com mailto:stephenashaf...@gmail.com sashaf...@ucdavis.edu mailto:sashaf...@ucdavis.edu I am no longer programming. I couldn't find an unsubscribe link on any of the recent messages. You might want to add that to make life easier fort everyone. Unsubscribe instructions may be found here: http://subversion.apache.org/mailing-lists.html -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Ancestrally Related Error Message
On 06/17/2013 11:19 AM, C M wrote: 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? Subversion doesn't think there is. Rather, it knows there isn't. Hence the message. The error was introduced to prevent a common mistake folks make when they misalign their merge sources and targets: $ svn merge ^/trunk branches ^C^C^Cdangit i meant to type branches/my-branch^C^Cagh! Two, how can I do to get around this error message? Well... the --ignore-ancestry option was *supposed* to make that happen for you. Perhaps there's a bug? You may need to give a more complete transcript of what you're trying, including command-line examples and such. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Ancestrally Related Error Message
On 06/17/2013 12:39 PM, C M wrote: I think my earlier mistake might have been that I was using the --reintegrate option. Without it, I make some progress, but still not quite what I am expecting. Again, given that trunk is empty, why the C (tree conflicts)? I would expect all of then to be A (additions), no? The DEV_WC currently only shows the two dirs which SVN correctly recognized as additions. c:\Temp\DEV_WCsvn merge --dry-run --ignore-ancestry https://path_to_branch/SCR_BR/ --- Merging r1191 through r1245 into '.': Do these revision numbers (r1191 and r1245) match what you'd expect? What happens if you do this: svn diff -r1190:1245 https://path_to_branch/SCR_BR/ Do you see exactly the additions that you would expect to see? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn 1.8 migration - directory deltification and revprop packing
One advantage of being in a room full of Subversion developers, specifically the guy that implemented all this stuff, is that I can ask him directly about how to respond to this mail. :-) Hopefully I will accurately represent the answers Stefan Fuhrmann just gave me to your questions. On 06/10/2013 03:05 PM, Thomas Harold wrote: a) Why are directory/property deltifications turned off by default? Stefan's jovial first answer was, Because I'm a chicken. :-) Fortunately, he didn't stop there. He explained that there is no known correctness risk -- you're not going to damage your repositories by enabling the feature. But he wanted to phase in the feature to allow time to collect real-world data about the amount of space savings folks are actually observing in their repositories. The feature is on by default in his proposed next version of the FSFS format. b) Is there a global setting file that can be used to enable directory/property deltifications? Or will we have to update the fsfs.conf file for each newly created repository in order to get this feature? In 1.8, you'll need to toggle this for each new repository manually. c) Is it a safe assumption that in order to apply this change to an older repository that we will need a dump/load cycle? Will we need a full dump or will an delta style dump suffice (--deltas option of svnadmin dump command)? Not exactly. You can apply the change to an older repository sitting behind a server still running 1.8, and any new directory/property lists will be stored in a deltified fashion. If you want retroactive deltification of existing data, then yes, you'll need to dump and load your repositories. But as explained in the release notes, you can dump and re-load right back into a previous version of the repository format if you'd prefer to maintain compatibility with older server versions. As for the --deltas option, that has nothing in the world to do with the types of deltas we're discussing here. (As an aside, I would highly recommend that, unless you need your dumpfiles to be smaller, avoid the --deltas option. The performance penalty of using it isn't worth it.) #2 - revision property (revprops) files packing a) Will there be a svnadmin pack command like there was for SVN 1.6? Or will we need to do a full dump/load of the repository to pack the revprops? The existing 'svnadmin pack' command will govern both revision and revprop packing, and will keep the two in sync with each other. 'svnadmin upgrade' will also take the opportunity to synchronize the packing status of the revision properties with that of the revision backing files. b) Does revprop caching only need to be enabled for http/https access and does it have any effect on svn+ssh access? (All of our users currently use svn+ssh access, but we are considering moving to http/https.) Each server has its own cache enable/disable configuration mechanisms, and both benefit from the revprop caching being enabled. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn 1.8 migration - directory deltification and revprop packing
On 06/11/2013 04:13 PM, Thomas Harold wrote: Thanks, the svn book is light on details of what exactly counts as minimum amount of work needed for svnadmin upgrade. svnbook-...@red-bean.com would be a great place to report that, though I'd suggest expanding your report with some context. The minimum amount of work for svnadmin upgrade is, in the general case, to run svnadmin upgrade. It's only when you start trying to take advantage of new features provided by the upgraded format that extra work is involved. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Lines duplicated in dest. file when merging back to trunk
On 06/04/2013 09:16 AM, Saffer, Simon wrote: I’m not subscribed on your mailing list so it would be great if you could Cc me in you responses. HTML is a really poor format for emails sent to software discussion lists, *especially* when the contents of the mail rely so heavily on formatting details such as the ability to notice trailing space characters on the lines of a text file. Please re-send your post in plaintext format. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: authentication error after upgrading client to svn1.8.0-rc2 (accessing a svn1.7.8 server)
On 05/31/2013 02:26 PM, C. Michael Pilato wrote: Filed an issue for this in the Serf tracker: https://code.google.com/p/serf/issues/detail?id=102 Just to follow up on this: the Serf devs have fixed the problem, and the fix will be included in Serf 1.2.1 (which should be released in the next couple of days). Thanks so much for your bug report!! -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: authentication error after upgrading client to svn1.8.0-rc2 (accessing a svn1.7.8 server)
On 05/31/2013 09:09 AM, Klaus Welch wrote: After upgrading the *client* to svn1.8-rc2 a simple svn info url gives the following error: $svn info http://domain:port/path svn: E120190: Error running context: An error occurred during authentication Playing around with svnauthz validate (server side) says that everything is fine. Oops. authz (authorization) != authentication. Wouldn't expect any problems with your access file rules based on the error message you got. It would seem at first blush that the Serf HTTP library that the client uses is having trouble communicating your user credentials to the server. You've mentioned that your server uses 'htdigest' style authentication. Are you able to obtain a wiretrace of a simple 'svn info' activity to share with us? (You can, of course, anonymize any sensitive information and just explain when you share it what you've masked.) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: authentication error after upgrading client to svn1.8.0-rc2 (accessing a svn1.7.8 server)
On 05/31/2013 12:06 PM, C. Michael Pilato wrote:
On 05/31/2013 10:45 AM, Welch, Klaus wrote:
On monday I'll check the serf version, remove client side credential,
carefully re-check all the build logs.
Hopefully something indicates where to look further.
As it turns out, I have been able to reproduce this problem on my laptop
with a simple Digest auth configuration. I'll debug after some lunch.
The failure occurs when Serf hits this condition (in its
auth/auth_digest.c:serf__validate_response_digest_auth() function):
/* Incorrect response-digest in Authentication-Info header. */
if (strcmp(rspauth, resp_hdr_hex) != 0) {
return SERF_ERROR_AUTHN_FAILED;
}
Still digging.
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: authentication error after upgrading client to svn1.8.0-rc2 (accessing a svn1.7.8 server)
On 05/31/2013 01:28 PM, C. Michael Pilato wrote:
On 05/31/2013 12:06 PM, C. Michael Pilato wrote:
On 05/31/2013 10:45 AM, Welch, Klaus wrote:
On monday I'll check the serf version, remove client side credential,
carefully re-check all the build logs.
Hopefully something indicates where to look further.
As it turns out, I have been able to reproduce this problem on my laptop
with a simple Digest auth configuration. I'll debug after some lunch.
The failure occurs when Serf hits this condition (in its
auth/auth_digest.c:serf__validate_response_digest_auth() function):
/* Incorrect response-digest in Authentication-Info header. */
if (strcmp(rspauth, resp_hdr_hex) != 0) {
return SERF_ERROR_AUTHN_FAILED;
}
Still digging.
After some more debugging, I find that the problem is the URI comparisons in
that function. On one side, the HA2 digest contributor has been calculated
using the actual URI of the PROPFIND request (.../!svn/rvr/...). On the
side of the comparison, a bit of path information is pulled from the Serf
connection's host_info structure. All works well for the OPTIONS requests,
which both hit the public URI of the repository. But that PROPFIND comes
along and the comparisons fail.
I'll need to take this up with the Serf developers.
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: authentication error after upgrading client to svn1.8.0-rc2 (accessing a svn1.7.8 server)
Filed an issue for this in the Serf tracker: https://code.google.com/p/serf/issues/detail?id=102 -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/21/2013 06:10 PM, Stefan Sperling wrote: Looks like this discussion has entered an infinite loop. ... which is a pity, because certain whole arcs of that loop are arguably off-topic for a users@ list. Design-related discussions really belong on dev@. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svnlook cat seems to swallow byte order marks
On 05/21/2013 10:53 AM, Alexander Veit wrote: Hi, it seems that svnlook cat swallows byte order marks (e.g. \xEF\xBB\xBF) from committed files. Therefore it is difficult to check for the presence or absence of BOMs in commit hooks. Can anyone confirm that this is a bug in Subversion (at least in version: 1.7.7)? Nope. Works as expected here. $ svnlook cat data/repositories/i18n-data utf8-chinese-bom.txt foo $ hexdump -C foo ef bb bf 75 74 66 38 2d 63 68 69 6e 65 73 65 2d |...utf8-chinese-| 0010 62 6f 6d 2d e5 90 8c e6 84 8f 0a |bom-...| 001b $ -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
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). -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development
Re: svn client does not convert line endings for some java files
On 05/03/2013 09:21 AM, Marek Slama wrote: Hi, not sure why but my svn client does not convert line endings for 'some' of my files. I did not find any rule for this. I have java project and files are text java sources. There is no mime type or eol-style property set on given files and some are with Linux line endings and some with DOS line endings. I have svn, version 1.7.5 (r1336830) compiled Sep 28 2012, 11:22:04. I do not know how to find out server version in case it is relevant. If I set eol-style property to native then it works. But such behaviour seems weird to me. Subversion is designed with a pretty clear policy governing such matters: don't screw up the user's files! If you happen to be coming from a CVS background, this will seem odd to you, because CVS's default mode of operation is to assume that a file is human-readable and that native newlines are desired, and will quite happily destroy the binary files you forget to add with the -kb flag. In Subversion, your file's contents are considered sacred. Unless you set the svn:eol-style property on a given file, well-behaved Subversion clients will not attempt to perform newline translation on that file. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn client does not convert line endings for some java files
On 05/03/2013 09:57 AM, Marek Slama wrote: So it seems I will have to set eol-style explicitly on all my text files. I will have to investigate how to set eol-style for newly added file for different clients my teammates use on Win. On Linux I can set it in config file using auto-props. Subversion applies the auto-props via configuration in its core libraries, not up in the command-line client layer only. You *should* find that all clients recognize the auto-props runtime configuration as well. See http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html for details on how Windows handles runtime configuration stuffs. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [RFC] Configurable default force mode for 'svn diff'
On 04/19/2013 12:47 PM, C. Michael Pilato wrote: I found that this can be done with the svn command line tools. However, --force must be used. Without --force, svn will see that the file has svn:mime-type prop set to application/octet-stream and refuse to do anything to a binary file. I nearly suggested this earlier, but my testing failed because I didn't know about the --force override! I think I'll file an issue against svnbook to point this out. That is, if it's not there already and I've simply forgotten that fact in the time since I documented it. :-) For those that care: https://code.google.com/p/svnbook/issues/detail?id=194 You know, in light of the fact you can use the runtime configuration to establish the constant use of an external diff tool, it seems that it would be beneficial to have another configuration knob that means My external diff tool can handle binary files, too, so please assume --force mode thankyouverymuch. Any opinions from the users@ readership on that idea? I got pretty much no feedback on this, but I liked the idea enough to implement it anyway. In r1478826, I introduced a new 'diff-ignore-content-type' runtime configuration option (which defaults to 'no'). Unless the feature is booed out of existence by the Subversion dev community, it should appear in Subversion 1.9. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn command --cl don't support names that contain chinese characters.
On 04/25/2013 05:14 AM, Philip Martin wrote:
Bluce Lu bluc...@51buy.com writes:
svn command --cl don't support names that contain chinese characters.
E,g. command “svn status -q D:\Project”, we see there is a changelist
named “好”, but when use command “svn status -q --verbose D:\Project
--ignore-externals --cl 好”, there is nothing to print.
Does svn st --cl 好 without the other options work? Are you using a
UTF-8 environment or some other encoding?
Chinese changelist names should work. This works on my Linux box:
$ svnadmin create repo
$ svn -mm import repo/format file://`pwd`/repo/f
$ svn co file://`pwd`/repo wc
$ svn cl 好 wc/f
$ svn st --cl 好 wc -v -q --ignore-externals
--- Changelist '好':
11 pm wc/f
Does that simple example work for you?
Code inspection tells me that when we set changelists (with 'svn
changelist') we convert the changelist name provided on the command-line to
UTF-8 (svn/changelist-cmd.c:58). But when we're stashing in the options
baton the value of the --changelist option, there's no such translation
(svn/svn.c:2162).
Your Linux box is probably using a UTF8 locale, Philip. Perhaps the OP's
Windows box is using something else (GB18030 or somesuch)?
Is this all that's needed?
Index: subversion/svn/svn.c
===
--- subversion/svn/svn.c(revision 1471390)
+++ subversion/svn/svn.c(working copy)
@@ -2159,7 +2159,8 @@
opt_state.remove = TRUE;
break;
case opt_changelist:
-opt_state.changelist = apr_pstrdup(pool, opt_arg);
+SVN_INT_ERR(svn_utf_cstring_to_utf8(utf8_opt_arg, opt_arg, pool));
+opt_state.changelist = utf8_opt_arg;
if (opt_state.changelist[0] == '\0')
{
err = svn_error_create(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: svn command --cl don't support names that contain chinese characters.
On 04/25/2013 08:31 AM, Philip Martin wrote: Yes, I was using UTF-8. I see the bug in iso-8859-1: $ svn cl å wc/f A [å] wc/f $ svn st wc --- Changelist 'å': wc/f $ svn st --cl å wc $ With your patch: $ svn st --cl å wc --- Changelist 'å': wc/f Committed my patch: Sendingsubversion/svn/svn.c Transmitting file data . Committed revision 1475724. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: How to setup a server?
On 04/25/2013 09:00 AM, Zé wrote: On 04/24/2013 08:52 PM, C. Michael Pilato wrote: The closest thing to official would be the Version Control With Subversion book (http://svnbook.org/). But don't expect to find an ordered list of steps to setting up a Subversion server, because that's just not the audience for that text. It would be nice if that sort of text was made available officially. At least I would be interested in it, and I believe others would too. Try reading Chapter 6 of the aforementioned book. It may be all that you need to read. The problem with an official step-by-step how-to, though, is that right out of the gate, you have decisions to make: * Which Subversion server do I want to use? (Apache+mod_dav_svn or svnserve) * Do I want my repositories to require authentication for access? If so, what kind (Basic, MD5, client-certs, Kerberos, ...) * Do I want encryption? (SSL? SSH tunneling?) * Do I want to enable access control on my repositories? What wants to be a linear step-by-step very quickly turns into a flowchart of possibilities with a potential series of dead ends determined by what software packages you do and don't have at your disposal. If you'd like to avoid setting up the server yourself, you might consider looking into a more turnkey solution uch as CollabNet's Subversion Edge (http://www.collab.net/products/subversion) or WANdisco's uberSVN (http://www.wandisco.com/ubersvn). Third-party service providers aren't an option. These aren't service providers. These products are downloadable packages which include all the stuff you need to run and administer a basic Subversion server on your own hardware/network/etc. I think it's fair to say that these products exist and are popular *not* because setting up a server is difficult, but simply because you can be sure that with a single download you eliminate the dead-ends and less-traveled paths in that flowchart of possibilities I was talking about earlier. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Error while updating
Ajay, Sorry to hear that you are dealing with frustrating Subversion problems. Please understand that the folks who read this forum do, in fact, wish to help you. The problem is simply that without some pretty thorough explanation of what you are experiencing, this task is pretty daunting -- too daunting to justify many of us diverting focused attention your way. (All pain, no gain...) Try to keep in mind that, to a degree, we also share a bit of the frustration of every user who suffers while trying to get Subversion to meet their needs. And if you're feeling frustrated after 2-3 days of your particular Subversion issue, imagine how some of us who've been fielding Subversion problem questions for over a decade must feel. :-) Look, the more information you can give us, the better. Help will always come as soon as possible. It's really kinda up to you to help define possible in this context. -- Mike On 04/24/2013 09:17 AM, Ajay Pawar wrote: I know it's not a hotline but as I am facing the issue from 2-3 days I am too much frustrated. -Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Wednesday, April 24, 2013 6:13 PM To: users@subversion.apache.org Subject: Re: Error while updating On 24.04.2013 07:03, Ajay Pawar wrote: Please help ASAP as the SVN user are not able to any work. This is not a support hotline. Messages like this Please help ASAP are simply rude in this context. Please think twice about what you wrote before sending it. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: How to setup a server?
On 04/24/2013 03:18 PM, Zé wrote: Is there an official Subversion guide to set a subversion server? The closest thing to official would be the Version Control With Subversion book (http://svnbook.org/). But don't expect to find an ordered list of steps to setting up a Subversion server, because that's just not the audience for that text. But not to worry! A Google search for guide to setting up a subversion server only returns 1.35 million hits. Surely there's *something* of value out there. If you'd like to avoid setting up the server yourself, you might consider looking into a more turnkey solution uch as CollabNet's Subversion Edge (http://www.collab.net/products/subversion) or WANdisco's uberSVN (http://www.wandisco.com/ubersvn). -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: External diff based on mime-type
On 04/18/2013 09:59 PM, Watson, Paul wrote: We have a diff utility designed for a proprietary file format. I would like for this theappdiff utility to be used if the file's svn:mine-type prop is application/the-app. Is it possible for svn to invoke an external diff based on mime-type? The Subversion command-line utility can't do this. But if you're a Windows user, you might be able to take advantage of TortoiseSVN's support for mapping MIME types to differencing tools. See the following for details: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-Progs-Adv -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: External diff based on mime-type
On 04/19/2013 10:20 AM, Watson, Paul wrote: From: C. Michael Pilato [mailto:cmpil...@collab.net] The Subversion command-line utility can't do this. But if you're a Windows user, you might be able to take advantage of TortoiseSVN's support for mapping MIME types to differencing tools. See the following for details: I found that this can be done with the svn command line tools. However, --force must be used. Without --force, svn will see that the file has svn:mime-type prop set to application/octet-stream and refuse to do anything to a binary file. I nearly suggested this earlier, but my testing failed because I didn't know about the --force override! I think I'll file an issue against svnbook to point this out. That is, if it's not there already and I've simply forgotten that fact in the time since I documented it. :-) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: External diff based on mime-type
I found that this can be done with the svn command line tools. However, --force must be used. Without --force, svn will see that the file has svn:mime-type prop set to application/octet-stream and refuse to do anything to a binary file. I nearly suggested this earlier, but my testing failed because I didn't know about the --force override! I think I'll file an issue against svnbook to point this out. That is, if it's not there already and I've simply forgotten that fact in the time since I documented it. :-) For those that care: https://code.google.com/p/svnbook/issues/detail?id=194 -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
[RFC] Configurable default force mode for 'svn diff' (was: External diff based on mime-type)
I found that this can be done with the svn command line tools. However, --force must be used. Without --force, svn will see that the file has svn:mime-type prop set to application/octet-stream and refuse to do anything to a binary file. I nearly suggested this earlier, but my testing failed because I didn't know about the --force override! I think I'll file an issue against svnbook to point this out. That is, if it's not there already and I've simply forgotten that fact in the time since I documented it. :-) For those that care: https://code.google.com/p/svnbook/issues/detail?id=194 You know, in light of the fact you can use the runtime configuration to establish the constant use of an external diff tool, it seems that it would be beneficial to have another configuration knob that means My external diff tool can handle binary files, too, so please assume --force mode thankyouverymuch. Any opinions from the users@ readership on that idea? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [RFC] Configurable default force mode for 'svn diff'
On 04/19/2013 12:56 PM, Watson, Paul wrote:
You know, in light of the fact you can use the runtime
configuration to establish the constant use of an external diff
tool, it seems that it would be beneficial to have another
configuration knob that means My external diff tool can handle
binary files, too, so please assume --force mode
thankyouverymuch.
Rather than a single diff tool, how about if a diff tool could be
specified for each mime-type? A mime-type without a diff tool specified
would use the default internal.
That's a sane request, and certainly not a unique one.
The unfortunate fact is that diff tools don't accept the same parameters, in
the same order, etc. So to make this happen within Subversion you really
kinda need a diff-command template for each MIME type:
{{{
[diff]
application/msword = C:\Utils\WordDiffer.exe %(file1) %(file2)
*/xml = C:\Utils\XMLDiff.exe --file1=%(file1) --file2=%(file2)
text/* = C:\Utils\GnuDiff.exe -a -u -L%(label1) -L%(label2) %(file1) %(file2)
}}}
Also complicating things is that Subversion currently expects that diff
tools honor a sort of interface specification in terms of returned error
codes. Obviously we could try to loosen some of that stuff up, but we don't
want to building knowledge of individual diff tools into Subversion. (We're
in the state we're in now because we did exactly that with GNU diff.)
So I still kinda think that the use of brokering script which *does*
understand the nuances of specific differencing tools is valuable. It could
even be a 'tools' Python script that the Subversion community maintains and
which ships with Subversion.
Of course, none of this actually answers the question I asked and upon which
my RFC was based. :-)
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: RFC822-style
If you're not opposed to using (if only as a shim layer) the C programming language, may I (and presumably we, with Daniel in mind) suggest that you use Subversion's existing parser API (svn_repos_parse_dumpstream2) and simply supply your own customized parser callback function vtable? On 04/16/2013 04:22 PM, Eitan Mosenkis wrote: I'm writing a svndumpfilter-like tool and I want to make sure it can handle anything svn can produce. On Apr 16, 2013 4:08 PM, Daniel Shahaf danie...@elego.de mailto:danie...@elego.de wrote: Eitan Mosenkis wrote on Tue, Apr 16, 2013 at 12:22:00 -0400: This would make it easier for implementers to write accurate parsers. Why are you re-implementing the parser? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Changelist support for svn patch?
On 04/17/2013 06:43 AM, Philip Martin wrote: [dev CC'd] Nick nos...@codesniffer.com writes: The 'patch' subcommand does not seem to support applying a changelist description to the files that are part of the patch. Any plans to support this? (Should I be asking this on the dev list?) That sounds like a useful feauture. The list of files affected by patch is not always readily available to pass to the changelist command. Would this behaviour be useful for other commands? Most of our other commands have explicitly provided targets, so adding a changelist to those targets is a simple modification to the previous command issued at the prompt. For some commands, the targets aren't all explicit, but the resulting set is trivial to reproduce with 'svn changelist' anyway. For example, you could run 'svn propset -R svn:eol-style=native', which will only touch files, but then 'svn changelist -R' will likewise touch those same files. 'svn merge' comes to mind as one that, like patch, does not always have explicitly named targets. It might be convenient for users if we supplied a sort of add-affected-items-to-this-changelist option to all of our schedule-a-working-copy-change types of subcommands. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Changelist support for svn patch?
On 04/17/2013 09:43 AM, Philip Martin wrote: The behaviour looks simple to define for 'patch' and 'merge', I was thinking about 'svn add --force' which marks all the unversioned files for addition. You mean, perhaps, 'svn add --force -R' (or some other non-empty depth). But that marks files *and* directories for addition. We can't even add directories to changelists today. :-( -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Changelist support for svn patch?
On 04/17/2013 11:32 AM, Philip Martin wrote: C. Michael Pilato cmpil...@collab.net writes: On 04/17/2013 09:43 AM, Philip Martin wrote: The behaviour looks simple to define for 'patch' and 'merge', I was thinking about 'svn add --force' which marks all the unversioned files for addition. You mean, perhaps, 'svn add --force -R' (or some other non-empty depth). Add is recursive by default. Doh. You're right, of course. But that marks files *and* directories for addition. directories to changelists today. :-( I imagine a new add-to-changelist option for commands would skip directories much like 'svn changelist'. But even if we do that it's not clear (to me anyway) which files should be added by 'svn add --force'. Let's examine the feasible options: 1. Mark all files under the explicit 'svn add' target with changelist. Meh... 'svn changelist -R' would do the same. 2. Mark only files added to version control by this command. To do this with a subsequent 'svn changelist' command would require a bit of scripting magic, so this seems like an interpretation that actually provides benefit. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Aw: Re: Subversion Ruby Binding: Server certificate verification failed: issuer is not trusted
On 04/12/2013 05:41 AM, Christian Plewnia wrote: So my problem is that I cannot find out how svn_cmdline_create_auth_baton() is mapped in the Ruby binding. It's not mapped. I wish it was, and may spend some time on that soon, because I need that function for the Python bindings. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Aw: Re: Subversion Ruby Binding: Server certificate verification failed: issuer is not trusted
On 04/12/2013 08:31 AM, C. Michael Pilato wrote: On 04/12/2013 05:41 AM, Christian Plewnia wrote: So my problem is that I cannot find out how svn_cmdline_create_auth_baton() is mapped in the Ruby binding. It's not mapped. I wish it was, and may spend some time on that soon, because I need that function for the Python bindings. Huh. Turned out not to be that difficult. (Translation: I'm an idiot and should have done this yars ago.) http://svn.apache.org/r1467302 I tested this with Python only, but I have no reason to believe that it won't work with Ruby and Perl, too. (Please do test it, though, if you can!) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: feature suggestion: add elements of repo browser to log window
On 04/11/2013 01:29 PM, Don Stock wrote: I suggest adding the repo browser URL dropdown and tree to the log window, where to save real estate it could for example show the tree in the URL dropdown or have a Show Tree button. I initially didn't understand why certain versions were missing from the log and tried to solve it while staying on the log window. If there had been a dropdown or button there I surely would have looked at it. I'm guessing you've contacted the wrong mailing list. This list (users@subversion.apache.org) is for users of the Subversion core distribution, which includes command-line utilities only (nothing GUI-like). As such, we don't have dropdowns, windows, etc. Perhaps you meant to contact the us...@tortoisesvn.tigris.org list instead? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Can't svnsync due to pre-revprop-change hook
On 04/03/2013 09:58 AM, Richard Cavell wrote: Thanks for the reply. I still have some sort of permission problem. I've removed my actual passwords from this transcript. Sorry for my lack of Unix-fu. Richards-MacBook-Pro:~ richard$ svnsync initialize https://svnbook.googlecode.com/svn/ file:///Users/richard/repo --sync-username richard --sync-password blah --source-username This is not a unix-fu issue. You've got your URLs switched in the 'svnsync init' command. svnsync thinks you're trying to copy data from your local repository to the public svnbook project repository. (Please don't do that. :-) ) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svnsync bug ?
On 03/26/2013 12:53 PM, KLOCK Laurent wrote: Well, what was the most confusing for me and made me think about a possible bug is the constant logging of the low water mark revision I agree. Choosing to log that rather than the replayed revision certainly violates the principle of least surprise. Worse (in my eyes, at least) is that svnserve alone is choosing to log this low-water-mark, while mod_dav_svn logs the actual replayed revision. That's just buggy. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svnsync bug ?
On 03/26/2013 01:24 PM, C. Michael Pilato wrote: On 03/26/2013 12:53 PM, KLOCK Laurent wrote: Well, what was the most confusing for me and made me think about a possible bug is the constant logging of the low water mark revision I agree. Choosing to log that rather than the replayed revision certainly violates the principle of least surprise. Worse (in my eyes, at least) is that svnserve alone is choosing to log this low-water-mark, while mod_dav_svn logs the actual replayed revision. That's just buggy. BTW, I'm testing a fix for this now, and will propose for backport to the next 1.7.x release too. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Keyword substitutions not being merged correctly
On 03/20/2013 02:24 PM, David Sandberg wrote: Things I had read elsewhere suggested that the keyword substitution takes place on the client during the commit process, but is it actually the case that the client only updates the committing user's working copy of that file during the commit, and then similarly updates any other user's working copy of that file with the same revision number during an update? If this is the case, then am I on the right track by thinking that the revision # of the merged file wouldn't be updated because the client doesn't regard a merge as the same thing as an update, and the revision # would only be updated when that merged file is committed (and to the revision of the merge commit in that branch, not the revision of the original trunk modification)? Perhaps the most non-obvious-yet-useful thing folks need to understand about Subversion and keywords is this: the Subversion server knows *nothing* about keywords or the substitution thereof. When keyword substitution is enabled, the Subversion client will substitute keyword values into placeholder locations embedded the file when copying the working file out of the pristines area of the working copy administrative subdirectory. When you commit changes to such a file, the client first un-substitutes the keywords found therein -- leaving only the keyword placeholders -- before transmitting those file changes up to the server. If the commit is successful, the Subversion client will again re-substitute your keywords into the working file, this time with an updated revision and last-modified stuffs. Likewise, when you update the file to receive someone else's changes, the client re-substitutes the keywords in the working file with the updated metadata. This is why your user isn't seeing updated revisions in his keywords after performing a merge -- because the line which contains those keywords in the file didn't *really* change from the server's point of view. It only appears to change on the client side because the client keeps refreshing that line of the file when required by changes to the file's local version. You should find that after accepting the merge from the server, the keyword remains unchanged in your working copy, but that after committing the merged changes, the working copy file is updated to reflect the new version you've just committed. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Keyword substitutions not being merged correctly
On 03/20/2013 02:52 PM, David Sandberg wrote: Thank you for that crystal clear explanation, which accounts perfectly for the observed behavior. I will add that I am not sure I agree with the correctness of that behavior, but that's only because it doesn't happen to fit our operational model, in which we cherry-pick revisions from the trunk into our release branch and then build archives for deployment to customers. The problem is that the resulting deployed files need to reflect the revision numbers that were committed into the trunk ... or at least some newer revision number than in previous builds. Yeah, so you've cherry-picked changes and applied them to some base revision. I think that, given some thought, you would agree that it would be incorrect for Subversion to claim that your working file is now at the revision you cherry-picked. I mean, to be at revision N implies that a file's history contains every change N, N-1, N-2 ... all the back to the file's origin. From what you've described, we could perhaps achieve that by committing the merged set of files to our release branch before we begin a build, but that seems like a backwards way to go about things when we may find ourselves still needing to make updates as part of completing the build, so we would be committing potentially broken revisions in order to get these keyword substitutions to update before the build process runs. Hrm. It seems to me you're placing far too much stock in the revision number, attributing descriptive powers to it for which it was never designed and is ill-suited to provide. Revision numbers alone cannot uniquely describe anything. You can have 15 files, each in one of 15 branches, each of which has slightly different file contents from the next ... and yet all 15 variations could carry the same $Revision$ keyword value (perhaps because all 15 copies were modified in the same revision). In such a scenario it becomes obvious that a revision number alone is insufficiently as a unique representation of that any one of those files. Rather, I would suggest that any attempt to uniquely identify a file's version include not just its revision number but also its path in the repository. path@rev is a truly unique coordinate in the Subversion repository. That might mean employing unique tags for your deployed configurations which are created directly from your cherry-pick-carrying branch working copies. $ svn checkout BRANCH_URL branch-wc $ svn merge [WHATEVER] SOURCE_URL branch-wc $ svn copy branch-wc ^/tags/MY_CUSTOM_TAG \ -m Tag baseline XYZ + cherry-picked revisions N, M, P, and Q Given such tags and the use therein of, say, the $URL$ keyword (instead of, or in addition to, the $Revision$ one), uniqueness can be achieved. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: confusing E195012 error: Unable to find repository location.(when location exists)
On 03/15/2013 06:48 AM, Tom wrote: Hi mailing list :) Please, help me to find out what is going on in our repository. I am preparing some automatic tool to work with svn and there is one thing, which is confusing to me. I want to do checkout to some revision: If I use peg revision everything is ok as expected: svn co https:\\...\branch10@11893 -r 11893 But when I try to ommit peg revision: svn co https:\\...\branch10 -r 11893 E195012 Unable to find out repository location occurs for https:\\...\branch10 occurs. Your first syntax instructs Subversion to: - find the 'line of history' that intersects the path https:\\...\branch10 in revision 11893 (the @ rev) - walk that line of history until you get to revision 11893 (the -r rev) - checkout that object (regardless of its path in the -r revision) As you can tell, the second step of that set of instructions seems redundant, right? And in fact, it *is* redundant. Your command-line could have just been: svn co https:\\...\branch10@11893 # without the -r The second command syntax instructs Subversion to: - find the 'line of history' that intersects the path https:\\...\branch10 in HEAD (the implied @ rev) - walk that line of history until you get to revision 11893 (the -r rev) - checkout that object (regardless of its path in the -r revision) Problem is that as I browse the repository in Tortoise svn Repo Browser for revision 11893 theres IS path https:\\...\\branch10. If I understand you correctly, back in r11893 there was a branch10. Later, that branch10 was moved elsewhere and a new branch10 came into being. That's fine. The question is: what is the very first revision for the directory which is called branch10 in HEAD? You should be able to get the answer using this command: svn log -q -r1:HEAD --limit 1 https:\\...\branch10 If the answer is a revision that's younger than r11893, then that explains why Subversion has complained. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: confusing E195012 error: Unable to find repository location.(when location exists)
On 03/15/2013 11:02 AM, Tom wrote: The question is: what is the very first revision for the directory which is called branch10 in HEAD? You should be able to get the answer using this command: svn log -q -r1:HEAD --limit 1 https:\\...\branch10 I tried this for both my branches: svn log -q -r1:HEAD --limit 1 https:\\...\branch10 svn log -q -r1:HEAD --limit 1 https:\\...\branch7 and for both of them I get revision: r69 Indeed both branches have the common ancester. If the answer is a revision that's younger than r11893, then that explains why Subversion has complained. For both the branches the revision is older. So, If I get it right, the expected behaviour in this case is: there is checkouted object found in the 'line of history' (in my case of https:\\...\branch7 the object was in r11893 in ancestor branch). This is great, because this was excpected also by me :) There is one remaining question: Why is this not working for the second branch: https:\\...\branch10 (error E195012 occures). Maybe there could arise some other complications about which I dont know ... Nevertheless I am glad to know about the expected behavior. If you were able to run 'svn log' all the way back to revision 69, then I would expect I would expect that your checkouts would all have worked, then. Weird. I, too, wonder what's going on... -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Need to restructure repo folders: Problem: SVN COPY is recursive
On 03/15/2013 03:11 PM, tim.willi...@ucb.com wrote: 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… I confess I got a bit lost in your description, but many times when folks have had major directory reorganization to do in Subversion, they've found the 'svnmucc' took helpful. svnmucc will be shipped as a first-class binary in Subversion 1.8, but has existed in Subversion's tools/ directory for many years. I recently(ish) documented for Version Control With Subversion the gist of the tool. See http://svnbook.red-bean.com/nightly/en/svn.advanced.working-without-a-wc.html#svn.advanced.working-without-a-wc.svnmucc for that write-up. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Need to restructure repo folders: Problem: SVN COPY is recursive
On 03/15/2013 04:07 PM, tim.willi...@ucb.com wrote: I am not very good at giving examples on a Friday afternoon, admittedly. I will try again. Original Folders \Barn\livestockNames.txt \Barn\chickens\chickenNames.txt \Barn\chickens\food\chickenFeed.txt New Structure I want: \NewBarn\livestockNames.txt \NewBarn\birds\chickenNames.txt \NewBarn\birds\chickenFeed.txt If I use SVN COPY to copy chickenNames.txt to the new folder: svn copy \Barn\chickens\ \NewBarn\birds\ I will get: \NewBarn\birds\food\chickenFeed.txt and I don’t want that folder called \food and its content. Ugh. This is another bad analogy. It is much more complicated because I have MANY files in each folder remapped to many different folders and subfolders, which is why I had hoped to use a non-recursive way to getting just the folder contents and not subfolders. I will look into svnmucc. Thanks for the tip! Just to be clear: svnmucc will also do recursive copies. The benefit it brings is the ability to do several remote commit-ish operations in a single revision (where 'svn' can only do a single thing -- or at least a single type of thing -- at a time). -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: confusing E195012 error: Unable to find repository location.(when location exists)
On 03/15/2013 03:58 PM, Daniel Shahaf wrote: C. Michael Pilato wrote on Fri, Mar 15, 2013 at 09:42:53 -0400: The question is: what is the very first revision for the directory which is called branch10 in HEAD? You should be able to get the answer using this command: svn log -q -r1:HEAD --limit 1 https:\\...\branch10 Need to pass --stop-on-copy too Well, actually, for the information I was seeking, --stop-on-copy *could* yield misleading results. However, your mentioning it does call to mind what *might* be happening -- a history gap in the lineage of branch10 which straddles the revision of interest (r11893). In other words, if there's a revision which appears in the output of `svn log -qv https:\\...\branch10` like: r11895 | ... Changed paths: A ...branch10 (from /some/other/path, r11890) where an object in a pre-11893 rev was copied in a post-11893 rev, that would also produce this symptom. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Issue
That malfunction comes from svn_token__from_word_strict():
int
svn_token__from_word_strict(const svn_token_map_t *map,
const char *word)
{
int value = svn_token__from_word(map, word);
if (value == SVN_TOKEN_UNKNOWN)
SVN_ERR_MALFUNCTION_NO_RETURN();
return value;
}
Not much to go on here, unfortunately. Obviously if the problem was the
result of an *entirely normal* unlock command, our regression test would be
expected to catch it. But I don't see enough in the issue report to help us
understand what was *not* entirely normal about this operation. (For any
devs taking note, token in the sense of the function above is not the lock
token, but is instead a serialized string token that the function is trying
to map to an internal integer code (e.g., an enum).)
On 03/14/2013 05:39 AM, rafael.zal...@infineon.com wrote:
Appeared during a normal “unlock” command.
---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html
Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.11\ext\subversion\subversion\libsvn_subr\token.c'
line 51: internal malfunction
---
OK
---
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: [SVN UPDATE] Is there a way to hide the summary of conflicts at the end ?
On 03/06/2013 10:48 AM, Colin Braly wrote: Hi there, When a svn update cause a conflict, SVN display at the end of the update a conflict summary : Summary of conflicts: Text conflicts: 2 Property conflicts: 1 Tree conflicts: 1 Skipped paths: 10 Is there a way to hide it ? I locally treat conflict (I print the C lines in red, U lines in light blue, etc.) and it would be great if I can hide the summary of conflicts. Thank you guys ! Colin, unfortunately for you, at this time we don't offer a switch for disabling the post-update summary. If there is a widespread desire for this, I'm sure it wouldn't be difficult to add a --no-summary option. Perhaps there's an opportunity here for you to spin up such a patch yourself, even! -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [SVN UPDATE] Is the --accept postpone option strickly included in the --non-interactive one ?
On 03/06/2013 10:39 AM, Colin Braly wrote: Hi there, As regards conflicts, with the command svn update : - SVN prompt : |# svn update Conflict discovered in 'test.txt'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options:| - With a svn update --accept postpone, nothing is printed (/take no resolution action at all and instead allow the conflicts to be recorded for future resolution/). - Nothing is print with a svn update--non-interactive either. Nothing is printed? That should be. You should at least see a line such as C text.txt that notes that your file is in a state of conflict. = Is the --accept postpone option strickly included in the --non-interactive one, for a svn update which bring one or more conflicts ? When in non-interactive mode, Subversion can't ask you how you want to handle conflicts. So, by default, yes, --accept=postpone is the mode that the update will operate in. You can, however, choose a different mode with --accept=SOMETHING_ELSE if you wish. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Failed to delete a folder
Hans Herrmann wrote: Hello, I have got the problem that I’m not able to delete any folder in the repository unless I’ve got the rights to read the repository root. I use the svn version 1.7.8 (r1419691) With svn version 1.6 everythings works fine. Here’s how to reproduce the error: 1. Don't have read/write rights to the root of the repository (for example repository “TESTREPO”) 2. Create a folder (for example folder “test” in project “private”) 3. use the following command to delete the folder: svn rm https://urltorepo/TESTREPO/private/test -m - fails with: „svn: E175013: Access to '/TESTREPO ' forbidden” Hans, I don't know if you've been following issue #4332 (http://subversion.tigris.org/issues/show_bug.cgi?id=4332), but I've committed a fix to a backport branch and have proposed it for inclusion in our next 1.7.x release. If you are able to do so, you might want to try out the patch (and offer feedback, thanks!), you can fetch it from http://s.apache.org/N24 -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Possible bug using svn:external with specific revision for directory that has been renamed
On 02/28/2013 03:36 PM, Jeffrey Pierson wrote: I'm seeing the following error when I attempt to update a working copy that has an svn external. svn: warning: W20: Error handling externals definition for 'MySharedProjectBeforeRename': svn: warning: W160013: File not found: revision 100, path '/trunk/MySharedProjectBeforeRename' svn: E205011: Failure occurred processing one or more externals definitions The external is set to a specific revision such as revision r100 and a rename was recently done on that directory as part of revision r101. The external references a project that is located in a separate repository on the same server and has always worked until after the rename. It appears as though when svnserve is resolving the path that it is resolving first from HEAD even though a specific revision was specified. below is an example of what the external definition looks like followed by both the versions of svn client and svnserve that I'm running. -r 100 /shared/trunk/MySharedProjectBeforeRename MySharedProjectBeforeRename You've accurately determined how Subversion is processing your externals definition. But it appears you aren't familiar with the general way in which Subversion processes URLs/paths and revisions. I suggest that you first read this: http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html Then, change your external definition to instead be: /shared/trunk/MySharedProjectBeforeRename@100 MySharedProjectBeforeRename -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: is that possible the same code under two different subversion service provider?
On 02/22/2013 10:07 AM, frame wrote: Thank you for all the replies and the link. Actually, I have just finished reading carefully the externals definition section of the book from top to the bottom. I think externals definition is the answer to our needs. Sorry, I didn't study Vendor Branch section. I am planning to put project/aaa/ in company B's repositoty, which the partner can access. Then in the main tree, hosted in company A's repository, at project directory level, I set the property of externals definition to point to www.companyB.com/aaa_repo Cool. The externals definition feature didn't even cross my mind, but yeah, I think that would suit you well. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn copy and history - quick question
On 02/14/2013 02:58 PM, Z W wrote: 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 ? I'm going to hesitantly say yes here. Yes, if you copy a directory the result will contain all the same stuff that the original had. Yes, it will have essentially the same history as the original. But perhaps it's best not to think about 'svn copy' copying history -- depending on how you interpret those works, that might imply a situation in which all the changes associated with the copied item are being duplicated, as if they've been made all over again. Rather, what happens is that 'svn copy' creates a single new version of an existing versioned file or directory as a continuation of the history of the original object, just at a different location and without discontinuing the life of the object at its original location. It may help to visualize it as a fork in the road of the copied object's historical path. Naturally, such a fork will look exactly like the original at first -- same content (for files), same children (for directories), same revision log of changes, etc. After all, every change made thus far in the history of that object is common to both sides of that fork. But from that point on, the copied object is free to diverge historically from the original. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: lock tree or branch - quick question
On 02/13/2013 03:04 AM, Thomas Hemmer wrote: Have a look at http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html. If you are in need of a conditional commit access control mechanism, you should consider using a start-commit hook - see http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.start-commit.html for details. Those are some good doc pointers, but be aware that the start-commit hook lacks the context to perform path-based conditional commit access. It's not until the pre-commit hook phase that the server knows which paths were modified as part of the commit. So, yes, you can do this conditionally from hooks, but use pre-commit rather than start-commit to do so. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [OPW] Introducing the 2013 Apache Subversion Intern
On 01/31/2013 07:54 AM, Nico Kadel-Garcia wrote: Although, there is something disturbing about the descriptionGnome Woman initiative. It's difficult not to picture short women with red caps and well groomed beards, one on every lawn in a suburb, mandated by their local housing association. (My sense of humor has sometimes been a source of despair for my wife.) LOL! (And as a guy whose sense of humor likewise encourages his wife's groaning, I salute you.) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: #4129 is reproducible Re: predecessor count for the root node-revision is wrong message
On 03/19/2012 01:25 PM, Philip Martin wrote: Philip Martin philip.mar...@wandisco.com writes: I can reproduce ove ra_local: svnadmin create repo svn mkdir -mm file://`pwd`/repo/A svn mkdir -mm file://`pwd`/repo/B svn co file://`pwd`/repo wc1 svn co file://`pwd`/repo wc2 svn ps svn:mergeinfo /P:2 wc1/A svn ps svn:mergeinfo /Q:2 wc2/B svn mkdir wc1/X svn mkdir wc2/Y svn ci -mm wc1 svn ci -mm wc2 wait Gives: Sendingwc1/A Adding wc1/X Sendingwc2/B Adding wc2/Y Committed revision 3. svn: E160004: Commit failed (details follow): svn: E160004: predecessor count for the root node-revision is wrong: found 3, committing r4 Is this problem specific to the FSFS backend? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: #4129 is reproducible Re: predecessor count for the root node-revision is wrong message
On 03/19/2012 02:24 PM, Philip Martin wrote: C. Michael Pilato cmpil...@collab.net writes: Is this problem specific to the FSFS backend? Yes, I think it is. For BDB the dag_node_t type in dag.c doesn't have a node_revision member. When update_ancestry does svn_fs_bdb__put_node_revision it writes to the database and subsequent svn_fs_bdb__get_node_revision will see the updated value. For FSFS the svn_fs_fs__put_node_revision call writes to the transactions subdir but the in-memory node_revision doesn't get changed. Gotcha. Thanks for the response. I remember when the BDB code had an in-memory node-revision structure and tried to maintain that using the trail construct. I remember also the day I purged the code of that mess. :-) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL - WC if URL contains externals
Alexey, We ask that folks send questions, concerns, and potential bug reports to users@subversion.apache.org. (I've taken the liberty of dropping dev@ and adding users@ to the distribution list of this response so that follow-ups go to the right place.) I wasn't able to easily reproduce this using Linux and a trunk version of the codebase. (I know that's two strikes against me in terms of trying to match your scenario. My 1.7 client build is horked at the moment, though.) One thing that comes to mind with the situation you are seeing is the possibility that an anti-virus software could be actively scanning the temporary files that Subversion creates and, in doing so, blocking access to those files from Subversion. Most modern anti-virus software packages offer a snooze feature of sorts -- you might try temporarily disabling your AV package and re-trying the checkout. If all goes well, consider adding your checkout area to the AV package's list of excluded scan directories. Good luck. On 02/16/2012 12:27 PM, Alexey 0 Moudrick wrote: Hello, dev, I've encountered an issue with *svn copy* command. I report it here because I did not find a way to report in in the issue tracker http://subversion.tigris.org/issues/reports.cgi. It cannot copy a directory by its url to local working copy if the directory contains valid svn:external property. Instead of correct copying, it shows error like this: *svn: E720005: Can't move* 'C:\t\wc\.svn\tmp\svn-8ED6923C' to 'C:\t\wc\externals-container-copy': *Access is denied.* The *repro.bat* composed according to recommendations http://subversion.apache.org/docs/community-guide/issues.html is attached (please rename it to repro.bat). *operating systems* where I tested: *Windows 7 Professional* x86-32bit SP1 Microsoft Windows [Version 6.1.7601] *Windows Server 2008 R2* Standard x64-64bit SP1 Standard Microsoft Windows [Version 6.1.7601] *svn versions* where I tested: svn, version *1.7.2* (r1207936) compiled Nov 30 2011, 02:05:23 svn, version *1.7.1* (r1186859) compiled Oct 28 2011, 13:40:58 Additionaly, this makes svncopy.pl http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svncopy contribution script fail on this error. Full output of repro.bat: C:\t*repro.bat* Base url for repo: file:///C:/t/repos Making a tree for import... Importing it... Checking out working copy.. *Creating valid svn:externals property...* property 'svn:externals' set on 'wc\externals-container' Sendingwc\externals-container Committed revision 2. *Copying externals container from URL to WC* U wc\externals-container-copy Fetching external item into 'wc\externals-container-copy\ext1': Checked out external at revision 2. Fetching external item into 'wc\externals-container-copy\ext2': Checked out external at revision 2. Checked out revision 2. *svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-169DB674' to 'C:\t\wc\externals-container-copy': Access is denied.* * * -- Best Regards Alexey 0 Moudrick = -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: error found; cannot report
Daniel is correct. Subversion uses UTF8 for path encoding. The book text is correct. -- Sent from my mobile device. Daniel Shahaf d...@daniel.shahaf.name wrote: On Mon, Jan 9, 2012, at 12:20, ppeder...@mapfreusa.com wrote: I have found what appears to be an error in the documentation. However, it appears that I cannot file a erratum report without having a gmail account. I don't want one of those; I just want to help fix this error. If you could forward this to the documentation people, Added them to the CC list :-) But, that said, without looking at the page, I think 0xC3 0xB1 is fine --- that's the UTF-8 byte sequence for 'ñ'. 0xF1 would not be valid UTF-8. Thanks for the report, Daniel that would be fine. Thank you. On this page: http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html españa is translated to espa%C3%B1a I think it should be espa%F1a instead. _ svnbook-dev mailing list svnbook-...@red-bean.com http://www.red-bean.com/mailman/listinfo/svnbook-dev
Re: Why do you need to grant root access to subversion repository??
There were two different things that changed in Subversion 1.5 that led to this. 1. Subversion started firing of OPTIONS requests for all operations, often against the repository root URL. 2. 'svn copy' and 'svn move' started allowing folks to copy/move multiple items at once, and the code was a little lazy about determining the right URL on which to base those multi-target operations. The incomplete fix Bert mentions is that (1) above has been remedied on trunk and proposed for backport to 1.6.x, but (2) has only been remedied on trunk. The backport was just too hairy, and the number of folks affected by the bug too small, to bother with. Voting is limited to committers in this case (a backport means not just I think we should fix this bug but also I've reviewed the code myself, it looks sane, doesn't appear to cause more problems, etc.. As for a workaround besides the obvious one (granting read access at the root), perhaps you could build the HEAD of Subversion's 1.6.x branch for yourself. If that's not an option, then short of rolling back to the latest 1.4.x release (the last releases before the bugs were introduced), you'll just need to wait for 1.6.10 to be released (assuming that more folks vote the backport into that branch). Keith Theman wrote: Thank You Bert, but what do you mean an incomplete fix ? and how can I vote for this? I can't believe this bug exists! Is there a work around while we wait for the fix? Ed From: b...@qqmail.nl To: xray...@hotmail.com; users@subversion.apache.org Subject: RE: Why do you need to grant root access to subversion repository?? Date: Tue, 2 Mar 2010 14:29:16 +0100 Hi, See issue #3242 (http://subversion.tigris.org/issues/show_bug.cgi?id=3242) An incomplete fix should be available (if it gets enough votes) in 1.6.10; see http://svn.apache.org/repos/asf/subversion/branches/1.6.x/STATUS. Bert Huijben *From:* Keith Theman [mailto:xray...@hotmail.com] *Sent:* dinsdag 2 maart 2010 14:25 *To:* users@subversion.apache.org *Subject:* Why do you need to grant root access to subversion repository?? Hello, We had been using svn 1.3. We had multiple projects in a single repository, and we had apache with mod_dav as a front end. We configured the access control list disallow root access: [myRepo:/] #* = r but then allowed appropriate user access to their project folders: [myRepo:/myProject] jdoe = rw Everything worked great, but then we updated to 1.6 and now we get permission errors unless we grant EVERYONE read access to the root of the repository! Everyone can see anything in the repository not good. What is going on? Ed Hotmail: Trusted email with powerful SPAM protection. Sign up now. http://clk.atdmt.com/GBL/go/201469227/direct/01/ Hotmail: Powerful Free email with security by Microsoft. Get it now. http://clk.atdmt.com/GBL/go/201469230/direct/01/ -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: svnlook pl --revprop does not work on transactions?
Olivier Dehon wrote: On Sat, 2010-02-27 at 08:43 -0600, Ryan Schmidt wrote: On Feb 27, 2010, at 08:36, Olivier Dehon wrote: On Fri, 2010-02-26 at 22:15 -0800, Alexey Neyman wrote: It seems that I encountered a bug in 'svnlook pl --revprop': it fails with the following message: $ svnlook pl --revprop -t 10547-86b /svn/test-svn svnlook: Invalid revision number '-1' Looks like you need to use svnlook info -t to access the values of the properties that are going to be set on the revision-to-be (svn:log, svn:author, ...) Why can't he use svnlook pl --revprop -t as he suggested? svnlook help pl suggests this should work. Agreed, it might be a missing feature. I was just trying to suggest a workaround for what the OP wanted to achieve. This is not an oversight. Subversion's public interfaces have always split trees of changes in the repository into two non-overlapping segments: revisions (which are sets of tree changes that have been promoted into new, numbered, revisions by the commit process), and transactions (which are sets of tree changes not yet promoted into revisions). We believe that the fact that those revisions are just promoted transactions (meaning, that you can still address them by their transaction name) is a bit of an implementation detail that needn't be revealed through the public interfaces to Subversion. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Managing Vendor Branches
Stefan Sperling wrote: On Sun, Feb 28, 2010 at 10:41:52AM -0800, Jeff Mott wrote: On Sun, Feb 28, 2010 at 4:28 AM, Stefan Sperling s...@elego.de wrote: On Sat, Feb 27, 2010 at 09:09:14PM -0800, Jeff Mott wrote: I just discovered that using --ignore-ancestry fixed the problem. This caused SVN to update rather than replace my working copy. What is the ancestral relationship between the branches containing the vendor drops? I assume they are just freshly imported directories? Stefan Yes, they are freshly imported directories. OK that makes sense. I found in the SVN book where this behavior is explained (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.ancestry). Fourth paragraph under the Noticing or Ignoring Ancestry section. I only wish they mentioned all this in the Vendor Branches chapter. If you have time to tweak the text to make it more clear (e.g. by adding cross-references to other sections) and to send a diff, I can commit the diff. The book's source code is pretty easy to understand, it's written in an XML format called 'docbook'. See http://svnbook.org for details on how to contribute. If you really can't make a diff, it's fine if you suggest what should be changed where so I or others can do it. But a diff would be much nicer cause it saves those who commit the changes to the book a lot of time (even if you're only changing a single line), and also because you can easily send more tweaks in the future (once you're set up, editing the book and sending a diff is really easy, and the book will improve each time). Contributions to the book are surprisingly rare, hence very welcome. Just for the record, I personally hope to continue fleshing out more first-class support for foreign repository merges, and I definitely have a TODO item to revamp the Vendor Branching section of the book to reflect the new hotness. It's the other 1658 items on the TODO list that get in the way... -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: unable edit existing log message
Subversion is going to try to execute the script as pre-revprop-change. Unlike on Windows where file extensions carry such valuable information as This can be executed (.EXE, .COM) and What kind of program or script is this (.BAT versus .EXE), to a Unix-y shell interpreter file extensions mean nothing. So it's safe (required, even, in Subversion's eyes) to name your script pre-revprop-change -- with no extension -- and include a hint to the shell interpreter as to which program to use to parse that sucker in the shebang line (the first line of the script): #!/bin/sh # Here's my pre-revprop-change hook script blah blah # blah... ... Charan wrote: I renamed .tmpl to.sh and also checked the execute permissions but still I get the same error. Thanks On Mon, Mar 1, 2010 at 12:20 PM, Tyler Roscoe ty...@cryptio.net mailto:ty...@cryptio.net wrote: On Mon, Mar 01, 2010 at 12:15:16PM -0800, Charan wrote: I have been trying to edit the already existing log message using TortoiseSVN tool but it is giving me the following error. I can see that the file pre-revprop-change hook exists in hook scripts folder with .tmpl extension and it is executable. Subversion won't exexcute hooks called *.tmpl. Rename the hook script to not have that extension and your Subversion server should start using it. tyler -- Thanks, Charan -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Happy 6th birthday, Subversion.
On this day six years ago, and after spending about four years in the collective community womb, Subversion 1.0 was released. Happy birthday, Subversion! -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: SVNParentPath + Recurse (or recursive)
Geert van Horrik wrote: Hi all, Is this feature planned on the roadmap? I have seen a lot of requests on the internet about this feature. What I want is this: /svn /svn/companies /svn/companies/mycompany /svn/companies/mycompany/product1 * /svn/companies/mycompany/product2 * /svn/companies/mycompany/product3 * /svn/companies /svn/companies/theircompany /svn/companies/theircompany/product1 * /svn/companies/theircompany/product2 * /svn/companies/theircompany/product3 * All items with a * should be a repository. I get requests for similar behavior in ViewVC. I agree that this would be a convenient feature to offer. So if you can't find an issue for this already in our issue tracker[1], please file one. Be sure to reference this thread[2] by way of demonstrating developer endorsement. -- C-Mike [1] http://subversion.tigris.org/issue-tracker.html [2] http://svn.haxx.se/users/archive-2010-02/0330.shtml -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Mirror a remote repository in a local branch
Ryan Schmidt wrote: On Feb 13, 2010, at 20:11, C. Michael Pilato wrote: The vendor branches section of the book was written before Subversion grew support for foreign repository merges. Wow, I did not know Subversion had grown such support. When did this happen? :) I kinda snuck it into the 1.5.0 release (and then we made some bugfixes in other 1.5.x releases). Don't tell anybody. ;-) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand
Re: Website: please add some content from the old links page
Cristian Rigamonti wrote: Hi, it seems the old http://subversion.tigris.org/links.html page was not migrated to subversion.apache.org. While I can understand that it's quite a burden to maintain a lot of information about third party tools etc, I think that some of the content of that page should be added somewhere on the new apache site: e.g. links to sample hook scripts http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ Note that the page content is still reachable at http://svn.apache.org/viewvc/subversion/trunk/www/links.html?revision=884848view=copathrev=900404 (thanks to the IRC folks on #svn for the hint :) This message would have a higher likelihood of being effective if aimed at the correct target audience. The folks that maintain the Subversion website hang out on the dev@ list. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand
Re: Svnsync - switching source and mirror
Bailey, Darragh wrote: Looking to setup a mirror to a locally hosted svn repo, however it's expected that in the future the role of which repo is the mirror and which is the master will reverse. Reading up on svnsync, there appears to be some suggestion that something happens with the 'svnsync init' command that is specific to the new mirror. I'm wondering if this will be an issue when changing which repo is the master and which is the mirror? It's not clear what exactly is set by this initial command. AFAICT it's only the last changed datestamp on rev 0, i.e. the initial create time of the source repository. It doesn't appear to copy the UUID, or provide an option to copy this, although maybe that's just because of the version I'm testing this on (1.4). All that 'svnsync init' does is set a bunch of revision properties on r0 in the new mirror repository. $ svn plist -v -r0 --revprop file:///usr/local/svn/subversion Unversioned properties on revision 0: svn:sync-from-uuid 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a svn:sync-last-merged-rev 39208 svn:date 2001-08-31T04:23:30.644170Z svn:sync-from-url http://svn.collab.net/repos/svn $ To switch your notion of source and sync repository, you'll need to set similar properties on the new sync repository. But you'll have to do so by hand (using 'svn pedit' or 'svn pset'), because 'svnsync init' gets fussy if you aren't operating on a clean repository. (In Subversion's trunk -- that is, 1.7.0-to-be -- I've added an --allow-non-empty option to 'svnsync init' which allows you to init an already populated copy of a repository as a mirror of the original. No more hand-editing of those revprops.) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: spam being forwarded from ad...@subversion.apache.org
Stein Somers wrote:
Oops sorry, misread the address.
ad...@subversion.apache.org does not spam me.
ad...@subversion.tigris.org started spamming after the old list closed.
Can some of you who are seeing this problem please report it to
feedback {_AT_} tigris.org ? Thanks,
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
Re: I think I'm in big trouble! (committed changes error)
Rolf Marsh wrote: Let me see if I can clarify this better... my (supposedly one and only) repository is on my desktop at home. I have one (1) working copy, which is on my flash drive. I normally do a commit after making changes when the flash drive is attached to the home desktop. This time, I did a commit before leaving for work while the flash drive was connected to the home desktop. I went to work, made some changes to the working copy, and foolishly did a commit while the flash drive was connected to my laptop. I don't believe there is a repository on the laptop, at least that I knowingly created. Did the commit succeed? If not, no big deal. Just take the drive home and commit again to the desktop repository. If it did succeed, then you've some explaining to do. Subversion won't likely let you commit changes (which are expressed as deltas against some known base, complete with checksums to verify file contents, etc.) easily into the wrong repository. Is it possible that your repository -- which you thought lived on the desktop box -- actually rests on the same flash drive? What does 'svn info' in your working copy reveal about the Repository Root? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: I think I'm in big trouble! (committed changes error)
I can't speak to AnkhSVN's behavior -- don't use it myself. What does 'svn status' in that working copy show? Are you local modifications still sitting there waiting to be committed? Rolf Marsh wrote: I believe the commit did succeed, because all of the AnkhSVN glyphs were gone... here is the current svn info on the flash drive; the F drive is on the desktop. I know the flash drive is the latest.. should I do another commit while it's connected to the desktop? L:\Inventory Program - Working Copysvn info Path: . URL: file:///F:/Repository/trunk/Prager%20Book%20Maintenance Repository Root: file:///F:/Repository Repository UUID: 13b279d9-a03c-d346-aaa8-def0303d8a0c Revision: 10 Node Kind: directory Schedule: normal Last Changed Author: Rolf Last Changed Rev: 6 Last Changed Date: 2010-01-07 15:55:58 -0800 (Thu, 07 Jan 2010) On 1/20/2010 6:50 AM, C. Michael Pilato wrote: Rolf Marsh wrote: Let me see if I can clarify this better... my (supposedly one and only) repository is on my desktop at home. I have one (1) working copy, which is on my flash drive. I normally do a commit after making changes when the flash drive is attached to the home desktop. This time, I did a commit before leaving for work while the flash drive was connected to the home desktop. I went to work, made some changes to the working copy, and foolishly did a commit while the flash drive was connected to my laptop. I don't believe there is a repository on the laptop, at least that I knowingly created. Did the commit succeed? If not, no big deal. Just take the drive home and commit again to the desktop repository. If it did succeed, then you've some explaining to do. Subversion won't likely let you commit changes (which are expressed as deltas against some known base, complete with checksums to verify file contents, etc.) easily into the wrong repository. Is it possible that your repository -- which you thought lived on the desktop box -- actually rests on the same flash drive? What does 'svn info' in your working copy reveal about the Repository Root? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
