Re: Status S
On 2011-11-12 01:00:10 -0600 Konstantin Kolinko wrote: Run "svn switch" on the file using its URL for trunk. That will switch it back to trunk. Best regards, Konstantin Kolinko Thanks, this solve the problem. But, is there a way to replace a file?. I work with interface in spanish then (to not duplicate the work) I would like replace the english interfaz. And then change the text strings from spanish to english. Is this possible?
Re: merge problem. impossible to revert deleted file
On 11.11.2011 16:51, Philip Martin wrote: You can't revert wc/D/f without reverting the replace of wc/D. Does this mean it's not possible to merge if the same dir is created both in trunk and in branch? Can the "replace" of the "duplicate" dir be avoided somehow? If not, it would be nice with an option to disable tree-conflict for dirs, just "accepting" existing dirs with same name. thanks, Gunnar.
Re: Status S
2011/11/12 Germán Arias : > On 2011-11-12 01:00:10 -0600 Konstantin Kolinko > wrote: > >> >> Run "svn switch" on the file using its URL for trunk. >> >> That will switch it back to trunk. >> >> Best regards, >> Konstantin Kolinko >> > > Thanks, this solve the problem. But, is there a way to replace a file?. I > work with interface > in spanish then (to not duplicate the work) I would like replace the english > interfaz. And then > change the text strings from spanish to english. Is this possible? How about using Unix's "cp" command (instead of "svn cp")? Best regards, Konstantin Kolinko
Re: Status S
Konstantin Kolinko wrote on Sat, Nov 12, 2011 at 11:00:10 +0400:
> 2011/11/12 Germán Arias :
> > Hi. After replace a file inside directory "staticOfRigidBodies",
> > seems like I have a branch:
> >
> > german@german-desktop:~/Instalados/FisicaLab$ svn status
> > ? FisicaLab.app
> > ? obj
> > M MIInformacion.m
> > S English.lproj/staticRigidBodies.gorm
> > M ChangeLog
> > M Spanish.lproj/staticRigidBodies.gorm/viga2FSE.tif
> > M Spanish.lproj/staticRigidBodies.gorm/vigasArm.tif
> > M Spanish.lproj/staticRigidBodies.gorm/vigaSE.tif
> >
> > After revert all files in dir "staticOfRigidBodies", the branch is still
> > there.
> > How can I delete it? Thanks in advance.
>
> Run "svn switch" on the file using its URL for trunk.
>
> That will switch it back to trunk.
By the way, running switch on the wc root --- for example,
svn switch `svn info | grep ^URL | awk '{print $2}'`
--- has the effect of undoing _all_ subtree switches.
Re: Difference between 'svn update' and 'svn checkout'
Wellington, are you by any chance trying to update your development server working copy with your post-commit hook? I'd recommend svn update or svn update --force over checkout simply due to the fact that it only brings changed files, not the whole repository (save network bandwidth, time, etc.) If the dev server wc is on the same server as your svn it should be as simple as cd /var/www/path/to/wc svn update . That said, I've never fiddled with hook scripts; only read about them. I'd love to see how you did this since I'd use it too... I just haven't gotten around to it.
Re: Network Share Checkouts
On Thu, Nov 10, 2011 at 12:48 PM, Ryan Schmidt wrote: > > On Nov 10, 2011, at 07:27, Nico Kadel-Garcia wrote: > >> Windows versus UNIX style end-of-line also becomes important. The >> "svn:eol" style for files in a shared repository will behave >> differently on Windows boxes accessing a CIFS share from a UNIX or >> Linux box via Samba than the UNIX or Linux box will provide with local >> or NFS access to exactly the same working copy if that is set. > > >> I spent a *lot* of time explaining this to verious people trying to >> use multiple platform shared access, and running headlong into the >> problems they thought they'd "cleverly" worked around. It became an >> adventure to explain why svn:eol should be deprecated, preferably with >> a claw hammer. > > Every time you bring this up I have to point out that what you're talking > about applies only when a file's svn:eol-style property is set to "native". > It does not apply when svn:eol-style is set to another value, such as "LF" or > "CRLF", nor does it apply if svn:eol-style is not set. No, it happens *every time* yous set it to "native" and wind up editing code in one OS and running it in another. It's particularly a problem when people use TortoiseSVN to a CIFS accessible for code or documents that get run on a distinct OS. For scripting languages it's particularly adventuresome. The replication and addition of a file other than with 'svn copy' requires manual or semi-automated setting of "svn:eol", or the new files will have a distinct configuraiton. Then when you *change* them to match, diffs get complicated. The whole thing is better dealt with by following git's model. "Don't touch the bytes once submitted, what comes out is byte-for-byte what you put in". I can see uses for 'Id' and 'URL', but this end-of-line confusion is just that far too often: confusion. >> Also, >> naming conventions become important, becuase CIFS does not support >> multiple files that only differ in capitalization for the same name, >> but a UNIX or Linux access to the same working copy will handle it >> merrily if the access is direct or NFS based. > > Case conflicts are an issue you'll want to avoid if you have Mac users too, > since the default Mac filesystem is case-insensitive too, just like on > Windows. I avoid commenting on the Mac experience, because I don't have one. (Wouldn't mind one, but I tend to install Linux on them.)
Re: Database Corruption in SVN
On Fri, Nov 11, 2011 at 6:18 AM, Waseem Shahzad wrote: > Is there any way that SVN database may be corrupted. Any story , Issue , > Experience…. Define "corrupted". Leaving write access to local users, such as is common with "file:///" based access, is begging for someone to screw up your repository with a command line mistake. And "split-brain" problems when you try to replicate repositories for high availability but don't quite get it right are not unheard of. There's also the problem I had early in my career when I tried to replicate a repository with a lot of debris cleared out of it but kept the same uuid. That caused serious pain. Also, bad disks and file system problems could corrupt the database. Losing a revision to bad blocks on your disk is a very real risk, which is another reason to do good backups. And that is true of *any* database without exceptional redundancy and error checking internal to it.
Re: Renaming on-the-fly?
On Thu, Nov 10, 2011 at 12:36 PM, Ryan Schmidt wrote: > > On Nov 10, 2011, at 02:43, P.N. wrote: > >> I want to check out an open source project (obviously from a *nix file >> system) using the same name differing only in case for two different files , >> which results in a conflict on windows. >> >> As I'm not a committer to the project, I cannot rename the file in the >> repository, so can I tell svn to rename it while checking it out? > > No; explain to a committer of that project how they can fix it. Use a *nix file system to do your actual work. "VirtualBox" works well for virtualization, even on Windows and Mac systems, and is free.
