Re: mergeinfo not inherrited when I thought it should
Hello, Here is some more information: >> Inside branch1/subfolder, we do a merge from trunk/subfolder. > > Do you mean trunk/project/subfolder here? yes > Anyway, branch1/subfolder does not have any mergeinfo, > since the previous merge was done on branch1. So Subversion > does not know that you have already merged the changes to line 1. Correct, but isn't SVN supposed to crawl up the tree to find mergeinfo? I thought this was the most simple usecase of inherited mergeinfo, which is described in various places, for instance here: http://help.collab.net/index.jsp?topic=/faq/mergeinfo.html > Merges from trunk to branch and vice-versa should always be done > from the root of the project (in your case branches/project/branch1) I can not believe this is true. I can not control the other users and I have had reports of similar issues from a few different users here, so it seems a real use case. > I don't think so, as I think Subversion did the correct thing, given the > information it has. Well, I still think it did not do the correct thing, as it had more info available than it actually used. > However, I recommend you to push for an upgrade of SVN, as I remember 1.5 was > not particularly good with merging. I have just tested with 1.6.13 on a test pc and it behaves exactly the same. By reading the details of inherited mergeinfo in the collabnet FAQ, maybe the bug is because mergeinfo is not up to date in the working copy and SVN uses that instead of contacting the repository. If this is the case, I would expect SVN to give me a "please update" warning when I do the merge command. Kind regards, Pieter-Jan
Re: syvnsync or svnadmin dump?
On Monday 01 Nov 2010, Les Mikesell wrote: > On 11/1/2010 4:23 PM, Taro Fukunaga wrote: > > Dear users, > > > > From what I've read, svnsync is *intended* for mirroring repositories > > (in read-only fashion) while svnadmin dump is for dumping a repository > > (for the purpose of loading it to a new repository). If I wanted to > > migrate a repository from one server to another, which solution is > > better? Is there a rule like, "never use svnsync for migration" or > > "svnadmin must be used for migration"? I don't find hard rules about > > this so I don't know if it's up for interpretation. > > Dump/load is probably a bit simpler since you can shut down your > svnserver/http remote access to make sure nothing changes and loading to > an empty repository sets the uuid from the dump to maintain > compatibility with checked-out workspaces. But, svnsync should work > too, or there wouldn't be much point to having it. You need to fix up > the hooks to match the old version either way. If downtime is an issue or if like me the dump/load takes a very long time then it is possible to do this whilst the original server is still running. Do the main dump/load then take a second dump using the --incremental option and start it at the next revision of the original dump. This second dump/load should be much quicker and the server downtime will be kept to a minimum. The dump/load approach is also useful if you want to prune the repository whilst moving it. ie, if you're splitting it into several new repositories or prermanently removing certain paths. -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
Re: syvnsync or svnadmin dump?
Campbell Allan wrote on Tue, Nov 02, 2010 at 10:49:38 +: > The dump/load approach is also useful if you want to prune the repository > whilst moving it. ie, if you're splitting it into several new repositories or > prermanently removing certain paths. You can also achieve some of these with svnsync --- e.g., if you set svnsync to access the source repository as a user who doesn't have authz permissions to read all of it, or if you set svnsync to mirror a subdir of the original repository into a new repository.
AW: unexpected mergeinfo results (v1.6.13)
> -Ursprüngliche Nachricht- > Von: Geoff Rowell [mailto:geoff.row...@gmail.com] > Gesendet: Freitag, 29. Oktober 2010 18:33 > An: Wöster Benjamin > Cc: users@subversion.apache.org > Betreff: Re: unexpected mergeinfo results (v1.6.13) > > On Thu, Oct 28, 2010 at 4:40 PM, Wöster Benjamin > wrote: > > Hi all, > > > > > > > > I'm currently trying to clean up explicit mergeinfos that are scattered > > throughout our repository. > > > > Some of these explicit mergeinfos were created because people used sparse > > working copies and didn't know about the impacts. > > > > So I'm trying to locate the pathes that contain non-inheritable mergeinfos, > > check that those merged revisions didn't affect the children of that path, > > > > and redo the merge with the -record-only option for that path. This way, I > > hope I can eliminate the non-inheritable mergeinfos as first step of the > > cleanup. > > > > > > > > I've attached a perl script, that will reproduce a sample environment (it > > needs svn and svnadmin to be in your path). > > > > It creates (in your current working directory) a repository and a working > > copy. The script creates some test data, creates a feature branch, > > > > simulates some work (including cherry-picking from trunk to the feature > > branch) and at the end, it merges the branch back to the trunk. > > > > Last but not least, it creates a cleanup branch. > > > > > > > > > > > > This is the point where I am with my productive repository, and it turns > > out, that the cherry-picked revisions cause the behavior I wouldn't have > > expected. > > > > The following is the session I use to reproduce the work till the point > > where I'm unsure if svn does things right. > > > > > > > > # creating the test data > > > > c:\mergeinfo>mergeinfo_fixture.pl > > > > c:\mergeinfo>dir > > > > Verzeichnis von c:\mergeinfo > > > > > > > > 28.10.2010 20:33 . > > > > 28.10.2010 20:33 .. > > > > 28.10.2010 20:28 2.108 mergeinfo_fixture.pl > > > > 28.10.2010 20:33 repo > > > > 28.10.2010 20:33 wc > > > > > > > > # navigate to the cleanup branch > > > > c:\mergeinfo>cd wc\branches\cleanup > > > > > > > > # checking for the non-inheritable merge info > > > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 > > > > /branches/feat_1/folder_1:2-6* > > > > /trunk/folder_1:4* > > > > > > > > So here it is. My understanding of the mergeinfo and the mergeinfo elision > > is, that once these revisions get merged into the children of that path, > > > > the explicit merge info should disappear. So I'm trying: > > > > > > > > > > > > (first with svn 1.6.12, which behaves the way I expected it to work) > > > > > > > > c:\mergeinfo\wc\branches\cleanup>svn -version > > > > svn, version 1.6.12 (r955767) > > > > > > > > c:\mergeinfo\wc\branches\cleanup>svn merge -r 3:4 --record-only > > "^/trunk/folder_1" folder_1 > > > > c:\mergeinfo\wc\branches\cleanup>svn status > > > > M folder_1 > > > > > > > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 > > > > /branches/feat_1/folder_1:2-6* > > > > /trunk/folder_1:4 > > > > > > > > So we see: r4 is no longer been marked as non-inheritable, but since it > > still contains other non-inheritable mergeinfos, > > > > the data is still stored as explicit mergeinfo. I'm fine with that. > > > > > > > > > > > > (now the same with the newer svn 1.6.13) > > > > > > > > c:\mergeinfo\wc\branches\cleanup>svn revert . -R > > > > Reverted 'folder_1' > > > > > > > > c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" > > --version > > > > svn, Version 1.6.13 (r1002816) > > > > > > > > c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" > > merge -r 3:4 --record-only "^/trunk/folder_1" folder_1 > > > > c:\mergeinfo\wc\branches\cleanup>svn status > > > > M folder_1\file_1 > > > > M folder_1\file_2 > > > > M folder_1\file_3 > > > > > > > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 -R > > > > folder_1\file_1 - > > > > folder_1 - /branches/feat_1/folder_1:2-6* > > > > /trunk/folder_1:4* > > > > folder_1\file_2 - > > > > folder_1\file_3 - > > > > > > > > Now, this is what I don't understand. I merged (well, recorded) the changes > > of revision 4 into a fully recursive working copy. > > > > The result according to the new client is, that the revision was only merged > > down to folder_1, not into its children. > > > > Those instead get an explicit, empty mergeinfo property set, which means: > > "Nothing has been merged to me so far". > > > > > > > > I'm unsure if this behavior is intended. It's correct that none of the > > changes would have ever touched those files, > > > > but didn't I tell svn to record that the revisions should be marked as > > merged? In my opinion, it simply refuses to do that (the 4* still exists), > > > > plus it adds more explicit mergeinfo to the childs (something I can't > > understa
comments on "Versionskontrolle mit Subversion, Für S ubversion 1.5"
Hello,
Thanks for the Book (and the translation) !
I've read the German translation (from Revision 3805) and have some comments on
that.
Because I'm referring to the German text, I'll continue in German. (Hoping this
is the right mailing list for both comments on the book and the translation)
One final English comment (because it is the same in the English version)
S xii (englisch .pdf, "Compiled from r3811")
"When this happens, the best thing you can do is email
and present your problem."
[It seems now to be us...@subversion.apache.org]
Ich hoffe, dass ich nicht zu oft blinden Alarm mache, da ich ja selbst noch
SVN-Anfänger bin. (Ich habe aber viele Jahre CVS verwendet, kenne also den
Vorgänger - mit allen Problemen, zu denen das führen kann...)
Die Seitennummern beziehen sich auf die .pdf-Datei. (und dort auf die
gedruckten Seitennummern). Meine Kommentare stehen in [eckigen Klammern].
Ich habe die Liste hier in verschiedene "Klassen" an Problemen unterteilt:
Inhaltliche Probleme --
S 28, Fußnote:
"4Und wenn Sie danach fragen, wird man Sie wahrscheinlich auf einer Schiene aus
der Stadt tragen."
[Das hört sich im Deutschen seltsam an - oder kapier' ich's nur nicht ?
Im Englischen steht "rail" und das gibt "Bahre" - wie ich zunächst vermutete -
als Übersetzung nicht her...
Verblüfft...]
S 51:
"Würde das den Autoren überlassen, veralterten die Informationen
unausweichlich."
[Das musste ich zwei mal lesen... Wie wäre es mit ", würden die Informationen
unausweichlich veralten" ?]
S 57:
"Locking"
[Hier ist jetzt bis S 77 ("Verzweigen und Zusammenführen") Englisch. Was wohl
schlicht heiß, dass die Übersetzung noch nicht so weit ist - oder ?]
S 81:
$ pwd
/home/user/my-calc-branch
$ svn log -v integer.c
r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Geänderte Pfade:
M /calc/branches/my-calc-branch/integer.c
* integer.c: Wazjub gefrozzelt.
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Geänderte Pfade:
A /calc/branches/my-calc-branch (from /calc/trunk:340)
Privaten Zweig von /calc/trunk angelegt.
[Ich hätte im Log-Kommentar 341 (statt 340) erwartet (siehe Abbildung 4.4 und
Checkout-Listing oben auf der Seite. Liege ich da schlicht schief ?]
S 245:
"Zum Zusammenführen von Änderungen in eine einzelne Datei:"
[=> "Zum Zusammenführen von Änderungen einer einzelnen Datei:" [?]
Ich habe den Text zunächst so gelesen, als würde der diff in einer getrennten
Datei landen.]
Tippfehler etc. --
S xvii,
"(Sie wissen schon, diejenigen, die sagen "Oh, du hast ein Buch geschrieben?",
und wenn man ihnen erzählt,
es sei ein Computerbuch, die Nase rümpfen.)"
[Die schließende Klammer fehlt]
S 13: (oben)
"dass eine Eihgenschafts-Änderung an einem veralteten Verzeichnis Eigenschaften
zerstören kann, die Sie noch nicht gesehen
haben."
[Ein 'h' zu viel in Eigenschafts"]
S 17:
Das legt Ihre Arbeitskopie in einem Verzeichnis namens subv ab, anstatt in
trunk so wie wir es früher schon einmal gemacht
haben. Das Verzeichnis subv wird angelegt, sofern es nicht bereits vorhanden
ist.
[Komma nach 'ab' fehlt - IHMO anyway...]
S 46: (Kasten)
"durch einfaches Durchlesen verstehen,"
[Ein 'i' fehlt]
S 50:
"Sie sind sich auch ziemlich sicher, dass sich Andere auch nicht dafür
interessieren."
['Andere' ist wohl ein Substantiv, also Groß]
S 52:
"bestimmte Schlüsselworte werden dessenungeachtet erkannt"
[ 'dessen ungeachtet' ? Ich bin gestolpert und die neue Rechtschreibung neigt
ja auch eher zu getrennt-Schreibung (schreibt man das nun zusammen ? Groß ?
oh-oh ;-)]
S 107:
"svn copy http://svn.example.com/repos/vendor/libcomplex/1.0 \
http://svn.example.com/repos/calc/libcomplex \
-m 'libcomplex-1.0 in den Hauptzweig bringen'"
[Ein 'a' fehlt in "Hauptzweig"]
Formatierung / Umbrüche etc. --
S 14: (grauer Kasten)
"Bindestrichen gefolgt von mehr als einem Buchstaben (z.B. -s bzw. -
-dies-ist-eine-langoption)."
[Aus dem '-' wird durch den Umbruch scheinbar ein '-']
S14:
"Der grundlegende Arbeitszyklus"
[Die Überschrift steht einsam auf der Seite. So etwas kommt öfters vor, ebenso
wie "Hurenkinder" und "Schusterjugen"
(http://de.wikipedia.org/wiki/Hurenkind_und_Schusterjunge)]
S 18:
"Nehmen Sie Änderungen an Ihrer Arbeitskopie vor"
[Auch wieder eine einsame Überschrift]
S23:
"Oder vielleicht haben Sie die Datei versehentlich aus der Versionsverwaltung
gelöscht:"
[Noch ein Schusterjunge]
S32:
"obersten URL Ihres Projektarchivs zeigen zu lassen, wie in svn log -r 2
http://svn.collab.net/repos/svn.";
[Der URL ist in die neue Zeile umgebrochen, dafür wird die Zeile zuvor
gesperrt, um den Blocksatz hinzukriegen...]
S 46:
"Wert der Da
Re: comments on "Versionskontrolle mit Subversion, F ür Subversion 1.5"
2010/11/2 Jost, Martin (NSN - DE/Ulm) : > Hello, > > Thanks for the Book (and the translation) ! > > I’ve read the German translation (from Revision 3805) and have some comments > on that. Although the book maintainers are active on this list, there is a separate list devoted to the book. See http://www.red-bean.com/mailman/listinfo/svnbook-dev There is also an open issue tracker you can file changes in. http://code.google.com/p/svnbook/issues/list
Windows client and SASL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Using: Win32Svn (32-bit client, server and bindings, MSI and ZIPs; maintained by David Darj) on both client and server. 131G C:\Users\johnb> svn --version svn, version 1.6.13 (r1002816) compiled Oct 3 2010, 23:19:41 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Server: Windows Server 2003 Client: Windows XP SP3 (in VPC), Windows 7 I get: 131G C:\Users\johnb> svn ls svn://Engineering svn: Cannot negotiate authentication mechanism TortoiseSVN has no problem operating on this repository, so either there's a bug in the binary, or, more likely, I haven't configured something in the command-line environment. The relevant portion of svnserve.conf: [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 and svn.conf: pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: DIGEST-MD5 sasldb_path: C:\Subversion\conf\sasldb JAB - -- John Alan Belli jabe...@pobox.com http:// coming soon (_...@___#PGP DH/DSS Key ID: 0x9F9A5233 RSA Key ID: 0xFD7399CD U/~ O- Available by finger and on various keyservers -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) - WinPT 1.4.2 Charset: UTF-8 iEYEARECAAYFAkzQZcUACgkQ2IsOhZ+aUjPGZACgmFtMzLcd70pg18I8xF46YYev YhoAnjZkPD4fRMpSg3idWcCQpfLVNvK4 =fWza -END PGP SIGNATURE-
DBM file authentication
Hi fellow SVN users, I am wondering about AuthDBMUserFile with SVN. I see people on this email list using AuthUserFile, and I have successfully tested authentication with AuthUserFile on my test server... But I believe that file format is restricted to two columns only with an end-o-line character required at the end of the encrypted password, (but I want more;) I would like to be able to append other info to the end of that line. I believe AuthDBMUserFile can handle this but I have not been able to get it to work. I have created a DBM file using dbmmanage that contains only one user:encryptedpassword, and I provided the path in the httpd.conf file ... but am I supposed to declare the file type in the httpd.config file? If so, how can I determine my file type that I've created? So far I have something like this: AuthDBMType default|SDBM|GDBM|NDBM|DB AuthDBMUserFile /path/to/MyDBMfile.pag I have also included this line in the block for my test repository": AuthDBMUserFile fileDBM AuthzDBMAuthoritative Off So my whole location block looks something like this: DAV svn SVNParentPath /path/to/testDir AuthType Basic AuthDBMUserFile fileDBM AuthzDBMAuthoritative Off AuthName "Testbed Subversion Repository" Require valid-user I can see mod_authz_dbm and mod_authn_dbm are loaded on my production server. So I think they are also on my test server, but I don't know how to check. Any suggestions? Thanks, Krista Andersen Consulting Engineer Investment Technology Group, Inc. 400 Corporate Pointe, office 835 Culver City, CA 90230 Office: 213.270.7570 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This message is for the named person's use only. This communication is for informational purposes only and has been obtained from sources believed to be reliable, but it is not necessarily complete and its accuracy cannot be guaranteed. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Moreover, this material should not be construed to contain any recommendation regarding, or opinion concerning, any security. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Securities products and services provided to Canadian investors are offered by ITG Canada Corp. (member CIPF and IIROC - Investment Industry Regulatory Organization of Canada), an affiliate of Investment Technology Group, Inc. Investment research products and services are produced and offered by ITG Investment Research, Inc. and not ITG Inc. (a FINRA member firm and SIPC member). ITG Inc. and/or its affiliates reserves the right to monitor and archive all electronic communications through its network. ITG Inc. Member FINRA, SIPC -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Windows Codepage: Problem SOLVED
Hi David, Bert, Alexey and everybody,
now it WORKS!! Thank you for your advises. 8-))
To solve my encoding problem, I had to:
- upgrade to cygwin 1.7
- set LC_ALL=de_DE.CP1252 (for Cygwin)
- chcp 1252(for Windows)
- use a True-Type font (Lucida Console)
=> Now Windows, Dos console, Cygwin and svn can talk with each
other with all German umlaut characters and such.
GREAT!
Paul.
> -Ursprüngliche Nachricht-
> Von: David Huang [mailto:k...@azeotrope.org]
> Gesendet: Montag, 1. November 2010 04:23
> An: users@subversion.apache.org
> Betreff: Re: Feature request: Support of Windows Codepage 850
>
>
> On Oct 31, 2010, at 1:35 PM, Paul Maier wrote:
>
> > Hi there!
> >
> > All output, that comes from the svn internationalization,
> shows correctly
> > on both codepages, 850 and 1252. E. g. error messages or
> "svn help ci". Good.
> > (Font in use is Lucida Console.)
> >
> > This shows, that it *is* possible for svn, to produce
> correct output on both
> > codepages, 850 and 1252.
> >
> > But output that comes from file data ("svn cat file") only
> prints correct with
> > Codepage 1252. Seems, that this output goes through a
> different piece of code,
> > that is not able to adjust to the Codepage in use.
>
> svn cat just outputs the file that's in the repository... if
> your file happens to be a a CP1252-encoded text file, but
> your console expects CP850, I don't think you should expect
> it to display properly. And how would svn even know that the
> file is a CP1252-encoded text file? While it does keep track
> of the MIME type, it doesn't keep track of charset
> encoding... perhaps I have a Chinese BIG5-encoded file in my
> repo; if SVN assumed it was CP1252 and tried to do a
> 1252->850 conversion on it, it'd corrupt the file.
>
> I think svn cat just needs to output the exact bytes of the
> file, rather than trying to do any conversion. If you want to
> do charset conversion, you could probably just pipe the
> output through iconv (available in Cygwin). E.g., svn cat
> filename | iconv -f cp1252 -t cp850
>
> > (I have to use Codepage 850, because Cygwin needs it.)
>
> I haven't tried it myself, but my understanding is that
> Cygwin 1.7 honors the locale environment variables. Perhaps
> try "set LC_CTYPE=de_DE.CP1252" or perhaps one of the other
> locale variables (LANG? LC_ALL?)=
German translation of "svn help st" is not showing, although provided in de.po
Hello, Obverved: All svn output, error messages, online help comes in German. But "svn help status", "svn help switch" and "svn help update" print in English. Expected: "svn help status", "svn help switch" and "svn help update" should print in German. The translation exists in the repository: http://svn.apache.org/repos/asf/subversion/trunk/subversion/po/de.po, lines 9493 - 9587 (svn help status), lines 9626 - 9667 (svn help switch) and lines 9723 - 9769 (svn help update). These are the binaries I use: http://alagazam.net/svn-1.6.13/Setup-Subversion-1.6.13.msi Thank you for having a look into that. Greetings, Paul.
