RE: Action needed to get critical SVN related fix in Windows 7 SP1
Hi, After reporting this issue as an official Microsoft support incident as MS partner (and most likely numerous reports from other Subversion users) it is starting to look like Microsoft decided to fix this in Windows 7 Servicepack 1. (They asked me if I was willing to accept a fix delivered in Servicepack 1 instead of an individual fix. And I think that is the best way to get this fixed for everybody) So I have no final confirmation yet (and I doubt I'm going to get one until they are ready to release Servicepack 1), but we got this issue on the servicepack schedule! Thanks to all of you that contacted Microsoft directly! Bert From: Erik Funkenbusch [mailto:e...@funkenbusch.com] Sent: donderdag 4 februari 2010 22:15 To: users@subversion.apache.org Subject: Action needed to get critical SVN related fix in Windows 7 SP1 Someone posted about what is essentially Subversion issue 3574 (http://subversion.tigris.org/issues/show_bug.cgi?id=3574) on the technet forums and received a response from Neal Christensen, the NTFS Lead Developer. He indicated that this is a known issue in Windows 7, but was not scheduled for inclusion in SP1 because it was not receiving much feedback. If you have access to send Microsoft feedback on this issue, it is in everyone's best interest if as many people do so as they can to get this issue included in SP1. This seriously affects those using Windows 7 as both a server and client for Subversion.
Re: Changing the native newline mode
On Fri, Feb 12, 2010 at 10:56:28PM -0500, Glenn Maynard wrote: Telling people don't do what you want to do; do what you don't want instead is not helpful. o rly? I haven't been following this thread closely but it seems that your complaint is the classic, Doctor, it hurts when I do this. Several people in the community have suggested, Then don't do that. I would take this sage advice (i.e. don't share working copies across platforms) or at least one of the proposed workarounds (I saw the idea of setting eol-style to CRLF; did someone suggest running unix2dos before using the working copy on your Windows box?) rather than complaining that the advice is not helpful. I can't find it right now but there was a presentation about the top ten ways *not* to use Subvesion. One of the entries was about using Subversion in a way that it was not designed to be used. This arises most frequently when people want to use Subversion as a backup mechanism, but I think it applies equally to your desire to use a single working copy across platforms no matter the cost. good luck, tyler
Restoring a hotcopy repo
Hi, I need to set up a new svn repository from a hotcopy backup. I understand that it is a simple procedure of just copying the files into the new repo and ensuring that the file access permissions are correct, but my concern is that the hotcopy contains a series of .txn directories which implies that the hotcopy was configured to do an incremental back-up, and my core concern is that when I move the content of the hotcopy, do I include the .txn directories or are these ommitted? Thanks in advance for taking the time to respond to my query Justin
High availability
Where one can find an article about HA-setup of subversion (preferable for gentoo)? I found two places: http://svn.haxx.se/users/archive-2007-01/1307.shtml (it just say that someone uses GFS) and http://www.wandisco.com/subversion/highavailability/ (It looks like commercial product, I don't read it all yet)
Re: Changing the native newline mode
On Feb 13, 2010, at 10:11, Tyler Roscoe wrote: I can't find it right now but there was a presentation about the top ten ways *not* to use Subvesion. One of the entries was about using Subversion in a way that it was not designed to be used. This arises most frequently when people want to use Subversion as a backup mechanism, but I think it applies equally to your desire to use a single working copy across platforms no matter the cost. In my experience, sharing a working copy between OSes can work, if you're aware of the limitations. These include: Checking out files with eol-style:native will give them the native line ending style matching the client that did the svn checkout. I am not certain what happens with svn update later: do files get the eol-style of the client currently doing the update or of the client that originally did the checkout? The latter would mean that the native eol-style was stored somewhere in the .svn directories by the client that did the svn checkout. To discover if this is the case, you could check out a working copy on UNIX and check out a working copy from the same URL on Windows and then diff them. If they differ, you may be able to use that information to patch the contents of the .svn directories on your UNIX box on the SMB share, in addition to running a tool like unix2dos or ux2dos to fix the line endings in the actual files. However, this advice will get me yelled at by the list, because we cannot recommend modifying the contents of the .svn directories manually for any reason. So I'm merely saying you could do this; I'm not recommending you do this. Symlinks don't work on Windows. If you check out a working copy on Windows that would contain symlinks on UNIX, you'll instead get a text file, whose contents is link followed by the path to the original item. If you check out on UNIX, you get a symlink. If you check out on UNIX on an SMB share that's hosted on Windows, I'm not sure what you get. Best advice is not to have any symlinks in your repository if you are going to be checking out on Windows ever. Windows and Mac filesystems are by default case-insensitive; UNIX filesystems are usually case-sensitive. If you need to use your repository from Windows or Mac clients, you will want to not commit files to the repository whose names differ only in case. There is a pre-commit hook in the Subversion source distribution that you can install that prevents such things from happening. Windows has several restrictions on the names files can have, which are listed in this Wikipedia article: http://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words You can commit files with these names on UNIX, but trying to move these to Windows will give you a cryptic error. So you should not commit files with these names to the repository. You could write a pre-commit hook to prevent the commit of such files if you believe this will be a frequent problem.
Mirror a remote repository in a local branch
Hi, I'd like to keep a mirror of the trunk of a remote directory in a branch of my local repository. My use case is that I have made modifications of a product for which I have only read access. As the product evolves, I'd like to update while keeping my modifications. I thought of keeping my work in the trunk and the evolutions of the remote product in a branch, and merge as necessary, simulating two teams working on the same repository. Is this possible/is there a better way to do this ? Thanks.
Re: Changing the native newline mode
On Sat, Feb 13, 2010 at 11:11 AM, Tyler Roscoe ty...@cryptio.net wrote: I haven't been following this thread closely but it seems that your complaint is the classic, Doctor, it hurts when I do this. Several people in the community have suggested, Then don't do that. I would take this sage advice (i.e. don't share working copies across platforms) or at least one of the proposed workarounds (I saw the idea of setting eol-style to CRLF; did someone suggest running unix2dos before using the working copy on your Windows box?) rather than complaining that the advice is not helpful. I've explained in reasonable detail why I want to do what I want, and why none of these workarounds work. Saying just don't do that is ignoring everything that's been said. It hurts when I breathe! Then what should you stop doing? On Sat, Feb 13, 2010 at 4:16 PM, Ryan Schmidt subversion-20...@ryandesign.com wrote: Checking out files with eol-style:native will give them the native line ending style matching the client that did the svn checkout. I am not certain what happens with svn update later: do files get the eol-style of the client currently doing the update or of the client that originally did the checkout? The latter would mean that the native eol-style was stored somewhere in the .svn directories by the client that did the svn checkout. To discover if this is the case, you could check out a working copy on UNIX and check out a working copy from the same URL on Windows and then diff them. If they differ, you may be able to use that information to patch the contents of the .svn directories on your UNIX box on the SMB share, in addition to running a tool like unix2dos or ux2dos to fix the line endings in the actual files. However, this advice will get me yelled at by the list, because we cannot recommend modifying the contents of the .svn directories manually for any reason. So I'm merely saying you could do this; I'm not recommending you do this. Even if that worked, I'm pretty sure it would break badly the next time a new directory was created from an update. I'll stick with manually repairing newlines for now. I suspect that it's not a massive project to actually implement this properly; fundamentally, it probably means adjusting svn_wc__get_eol_style to allow substituting native for one of the other EOL modes, based on a working-copy-local setting (not a stored property). When this setting is changed, any affected eol-style:native files would need to be converted (nothing new here; changing eol-style itself does exactly that). The tricky part is in the supporting details: where to put that setting and how to change it, what happens if you svn switch a directory with this setting, etc. Anyhow, while it might be too niche a feature for inclusion in Subversion, it's definitely not outside the overall design, as Tyler suggests. This fits very naturally into Subversion's concept of newline handling. -- Glenn Maynard
Re: Mirror a remote repository in a local branch
On Feb 13, 2010, at 15:43, v...@bidouille.org wrote: I'd like to keep a mirror of the trunk of a remote directory in a branch of my local repository. My use case is that I have made modifications of a product for which I have only read access. As the product evolves, I'd like to update while keeping my modifications. I thought of keeping my work in the trunk and the evolutions of the remote product in a branch, and merge as necessary, simulating two teams working on the same repository. Is this possible/is there a better way to do this ? The Vendor Branches section of the book talks about this scenario. There are tools to help you automate this, including the Perl script svn_load_dirs.pl and the Ruby script Piston.
Re: Changing the native newline mode
On Sat, Feb 13, 2010 at 7:10 PM, Ryan Schmidt subversion-20...@ryandesign.com wrote: svn export already has a --native-eol switch. This is easy because after exporting, Subversion doesn't have to deal with that directory anymore. But as a fellow user I think it would fit nicely to have the same switch on svn checkout, which would make that working copy always use the indicated native eol-style. Where to store this fact? In Subversion 1.7, working copy metadata will no longer live in .svn directories but in a central sqlite database, so there's probably a place in there where native eol-style could be stored. If Subversion does not already store the native eol-style of the working copy somewhere, this would probably be a good thing to add, regardless of whether we add a mechanism for requesting an alternate eol-style. A database representing the whole working copy? That's odd--I can't think of how that could generally handle actions like cloning a whole WC (cp -a wc1 wc2), pulling a piece out of a WC creating a new WC as a result (mv wc1/trunk .; rm -rf wc1) and renaming a WC (mv wc1 wc1~), all of which work with the current system (and all of which I use with varying frequency). Putting text-base in Sqlite would be unfortunate. One of the great things that could be done with the current format would be to support COW filesystems, which are under active development and hopefully will be fairly common in a few years. That would eliminate the 2x data overhead, while still supporting client-side diffs. I'm not sure that Sqlite is any good at storing large, changing files, either (database fragmentation). (I don't know what the actual design is looking like; I've looked over http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design, but of course it's rather hard to grasp the overall design from a thirty page design notepad.) I'm not sure we need a mechanism to switch an existing working copy to a different native eol-style. If we do, svn update --native-eol CRLF would be one possible syntax to consider. That's true, and simplifies the idea significantly. I do think it's reasonable to require this be set at checkout time. Another category of use cases comes to mind: svn diff can operate across WC's, so it should function across WC's checked out with different newline styles. (I don't see myself actually trying to implement this--not in the next few months, anyway--so I didn't poke in to see how hard this would be.) However, rather than adding a third function to svn switch, I'd be more in favor of going the other way: reducing switch to a single functionality I'd avoid any design that involves rearranging core features like svn switch, which I suspect would make it a much harder sell to the core developers, who would rightly ask why are we making major interface changes for a minor feature?. -- Glenn Maynard
Re: Changing the native newline mode
On Feb 13, 2010, at 19:00, Glenn Maynard wrote: A database representing the whole working copy? That's odd--I can't think of how that could generally handle actions like cloning a whole WC (cp -a wc1 wc2), pulling a piece out of a WC creating a new WC as a result (mv wc1/trunk .; rm -rf wc1) and renaming a WC (mv wc1 wc1~), all of which work with the current system (and all of which I use with varying frequency). Putting text-base in Sqlite would be unfortunate. One of the great things that could be done with the current format would be to support COW filesystems, which are under active development and hopefully will be fairly common in a few years. That would eliminate the 2x data overhead, while still supporting client-side diffs. I'm not sure that Sqlite is any good at storing large, changing files, either (database fragmentation). (I don't know what the actual design is looking like; I've looked over http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design, but of course it's rather hard to grasp the overall design from a thirty page design notepad.) You bring up a lot of the same questions I have about the new working copy design. I assume the developers have considered all of this carefully and are making the best choices they can. I plan to wait until 1.7 is released and then just see what's happened. I understand some (all?) of this is already implemented in trunk so you can of course build from there and see how it works already.
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: Restoring a hotcopy repo
Greetings, Justin Connell! I need to set up a new svn repository from a hotcopy backup. I understand that it is a simple procedure of just copying the files into the new repo and ensuring that the file access permissions are correct, but my concern is that the hotcopy contains a series of .txn directories which implies that the hotcopy was configured to do an incremental back-up, and my core concern is that when I move the content of the hotcopy, do I include the .txn directories or are these ommitted? Hotcopy is a snap of working SVN repository. If you're concerned, you could just point your SVN tools to the new repository made from backup and see if it works the way you expect it to be. Then switch main server over to the new location. The txn dirs likely indicate stalled transactions, lookup documentation about the ways to cleanup repository from them. Yet again, you should not be need to mess with hotcopied files by hands - only using standard Subversion utilities. -- WBR, Andrey Repin (anrdae...@freemail.ru) 14.02.2010, 8:09 Sorry for my terrible english...
Re: Changing the native newline mode
On Feb 13, 2010, at 23:09, Andrey Repin wrote: Second, don't join replies to multiple authors in one post - it's frustrating. Actually, the mailing list guidelines encourage us to do this: http://subversion.apache.org/docs/community-guide/mailing-lists.html#when-to-post
Re: Changing the native newline mode
On Sun, Feb 14, 2010 at 12:09 AM, Andrey Repin anrdae...@freemail.ru wrote: First, I said already, AnkhSVN. And I've already explained that I want to use my existing Linux CLI to manipulate all of my repositories, so I don't have separate SVN interfaces for each of my working copies. That's the *whole point*. A Windows GUI doesn't help me do that at all, nor do any of the other things you've suggested. If I wanted to use a Windows Subversion client, I wouldn't have been here in the first place. Do you think I'm not aware of their existance? On Sun, Feb 14, 2010 at 12:36 AM, Ryan Schmidt subversion-20...@ryandesign.com wrote: Actually, the mailing list guidelines encourage us to do this: And it's fairly standard practice, at least when replying to close neighbors in a thread. -- Glenn Maynard
Re: Changing the native newline mode
On Sat, Feb 13, 2010 at 9:56 PM, C. Michael Pilato cmpil...@collab.net wrote: You can't think how that would handle those actions because many of them won't be handled at all. 'cp -a wc1 wc2' will result in a non-working-copy named 'wc2'. 'mv wc1/trunk .; rm -rf wc1' will result in a non-working-copy named 'trunk'. And so on. There's been talk of adding 'svn' tool support for these actions, of course, but I don't know if the details have been decided upon. Why don't you chime in over on dev@, since that's rather the place to discuss Subversion's development? That's probably redundant--I'm sure all of this is being thought of, but I'll summarize what comes to mind, just in case. Based on looking through [1] some more, it looks like cp -a wc1 wc2 and renaming working copies should work fine, since the database is inside the working copy, and will just get copied along with the rest. (That's the only place I could imagine a working-copy-global database going anyway, else there would be endless problems with finding the database over NFS and in shared directories, knowing when to purge old databases, etc.) Hopefully there'll still be a way to slice out a piece of a repository (mv wc1/trunk .; rm -rf wc1), which wouldn't work if it's dependent on a global db at the top. [1] http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design And the other part from the earlier mail: Putting text-base in Sqlite would be unfortunate. One of the great things that could be done with the current format would be to support COW filesystems, which are under active development and hopefully will be fairly common in a few years. That would eliminate the 2x data overhead, while still supporting client-side diffs. I'm not sure that Sqlite is any good at storing large, changing files, either (database fragmentation). I have a few gigs of ~5 meg files in Subversion, and the idea of storing large blocks of data in SQLite is a bit scary; I don't think it's designed for blobs that size. Anything that lumps files together like this is effectively subjected to two layers of fragmentation instead of one (filesystem + db). I'm very happy to see the beginnings of svn obliterate support. I brought that up quite a while back, but people at the time seemed certain that there's never a need to remove old data (which I've had to do many times on our CVS repositories due to disk space limits and prevented us from using Subversion for a long time). -- Glenn Maynard
