|
I'm new to managing SVN so I hope you don't mind me asking something I might find in the course of reading the Red Bean book. We run SVN updates on most machines overnight to keep them current, but some things rarely need updating and some teams don't need certain files updated for the course of their own work, and so we would like to save time and network resources for the update by having SVN leave them as they are. If I understand right, since these are versioned files I can't use SVN:Ignore for this. Is there a solution other than replacing the SVN update command for the whole project with many smaller commands to update bits of it at the exclusion of the offending files?
|
#
¿
Aug 3, 2009 10:44
|
|
|
|
| # ¿ Apr 29, 2024 10:22 |
|
|
tef posted:http://svnbook.red-bean.com/en/1.0/ch07s03.html I'm not sure this is what I'm after, it appears to let me have parts of the project sync with different locations, rather than not sync at all. To elaborate, I would like to have something on the clients side that stops certain folders and files in the Local Copy being updated when SVN update is run on the whole project.
|
|
#
¿
Aug 5, 2009 17:33
|
|
|
Avenging Dentist posted:http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html It appears that can only be applied to stuff not already in the repository. The files are already present and necessary, and I don't want to have to remove them on so many machines for the sake of this. What if I remove, backup or otherwise disable the .SVN folder in directories (or is it the parent directories?) of files that I want to go un-updated? I could have a script that renames or moves the .SVN folders and then puts them back after the update. Edit: No it won't, Windows won't let me rename a folder back to .svn and running SVN update with a missing one will make it demand a cleanup first. BizarroAzrael fucked around with this message at 12:39 on Aug 6, 2009 |
|
#
¿
Aug 6, 2009 12:27
|
|
|
I've got a guy who would like a script for build machines to revert all local changes and update to a specified version. Is the way to do this just to svn revert the whole project, then svn update it all, or is there something more elegant? Revert seems to only allow you to change stuff to the HEAD revision.
|
|
#
¿
Aug 20, 2009 16:35
|
|
|
Avenging Dentist posted:"svn revert" reverts to the version you checked out, not to HEAD. Ah, so I will need a separate Update command, cheers.
|
|
#
¿
Aug 20, 2009 20:59
|
|
|
I've got a pretty big issue here, can anyone talk me through causes of conflicts in SVN after updates? A guy ran an SVN Update on his project last night after committing a number of changes. The changed files came up as conflicted and are now marked as unversioned in the directory, having apparently reverted to how they were priot to him making changes, so he has to delete them and revert the folder, which results in him getting the files with his committed changes from the previous day. I've had several people run the same update script for a few weeks now, and this is the first time I've come across this. BizarroAzrael fucked around with this message at 10:56 on Aug 26, 2009 |
|
#
¿
Aug 26, 2009 10:46
|
|
|
Itaipava posted:I'm no guru, but could you elaborate on what this "update script" does more specifically? Usually, SVN won't (shouldn't) let you perform a commit if your working copy is out-of-date (to avoid repository conflicts on stuff that's been committed by other people), but you're telling us that he first committed and then updated, so it sounds like that wasn't the case. The script runs a backup (copies folder to folder_backup) then SVN cleanup and then SVN update on the whole project. It determines a revision number based on a file published by another department who will check the build the following morning and publish necessary changes to make it work. The script also runs a build and compiles the project. So this guy updated overnight to what was probably essentially the HEAD revision at that time (unless someone was up really late submitting changes, which I am not aware of anyway) and arrives the next morning with that last night's revision on his machine. He made some changes, committed them and did a few more local changes before leaving once more and running another overnight update. He was the only one changing these files (pretty sure he was getting locks for everything) and when the update ran they were conflicted.
|
|
#
¿
Aug 26, 2009 18:24
|
|
|
I have a guy who has found that when he tries to SVN update the project, he gets told that there are locks on the project and he should run an SVN cleanup. I had a similar issue that was fixed by releasing the locks through Tortoise, rather than the cleanup SVN suggests, but in this case I just get told to do a cleanup. On attempting a cleanup, I get an error saying that a [file].svn-base file in the hidden .svn folder can not be copied into a [file].tmp.tmp file. I don't understand where his locks (or mine) came from, but more importantly I need to know how to straighten out his cleanup so he can update into a working build tomorrow.
|
|
#
¿
Sep 2, 2009 12:21
|
|
|
Okay, new problem. I would like to version my SVN update scripts, and so have a folder of batch files in the repository so that a)everyone has access to them and b)we can make sure they don't get changed and screwed up for everyone (right now they are on a shared drive) This presents the problem of the update scripts being changed by the SVN Update that they have called, which can screw things up. I could change the Update command to exclude the scripts directory, but I would like to keep them up-to-date for everyone in case I need to make a change, and I don't want to have to revise a script if they ever change or add anything to the root directory. The master script, which calls all the other scripts to perform the update, is to be versioned as Update.bat.template, so users will need to cut off the ".template" and unversion it for it to work. Doing this for the other scripts seems impractical though, I don't want users having to muck around with them themselves. I thought about having them versioned as .templates as well, and having the master script rename them. Would it work to have the script rename them all by removing the .template? Then the update would restore the original .bat.template files which would be used next time the update runs. I think I've just hit on the solution whilst writing this, but I'd like to hear what anyone thinks. Edit: Weird question: Can I version an empty directory? I'd like all users to have a place to put all the log outputs of the update script without the script throwing up an error every time after the first because the folder is already there. BizarroAzrael fucked around with this message at 16:55 on Sep 9, 2009 |
|
#
¿
Sep 9, 2009 12:25
|
|
|
If there a good way to find conflicting files in a working copy without attempting an update on it? We have guys that often get conflicts and it would be nice if I could scripts something that finds the problems so they can be fixed by hands, rather than have them kill the overnight update and the subsequent build process.
|
|
#
¿
Sep 18, 2009 14:56
|
|
|
If I do an update to the head revision, is there some way to capture the specific revision number for later use? I would like for my update script to be able to make sure it's not going to "update" to an old version. Basically check a record of yesterday's revision against the current one, do the update and record the new revision number for tomorrow. Edit: I think I have it, I can issue an SVN info command and have the output written to a file, then grab the current version number from it. Kind of embarrassed I didn't think of it sooner. BizarroAzrael fucked around with this message at 15:10 on Sep 29, 2009 |
|
#
¿
Sep 29, 2009 10:36
|
|
|
Okay, back to my recurring problem with conflicts in SVN. If a guy has an unversioned file in the project, and someone commits a file by the same name, the resulting conflict kills the update. Updates can take over an hour so it's done at night, and is followed by a build on the resources within, so this leads to a lot of lost time. The best I can think of to solve this is to do an SVN status on the whole project, outputting to a text file, pick out all the unversioned files using a script, back them up elsewhere and copy them back after the update. The end result for files that would be conflicted is that they remain the same but are now versioned and marked as locally changed, as far as I can see. This really isn't elegant though. Everyone keeps unversioned files that they will never commit. Can anyone propose a way to find only the files that are about to be conflicted and fix them so they remain the same and become versioned, or maybe renamed to filename.txt(1) or something?
|
|
#
¿
Oct 7, 2009 18:01
|
|
|
Dromio posted:Maybe I misunderstand the problem, but if you don't want the files in source control it's usually a good idea to use svn:ignore. No, I don't want to keep the file out of version control, and I want the versioned copy to be received by, or at least available to, everyone. Having an ignore stopping the versioned copy being recieved could stop something critical being received, and would need to be done manual by users, possibly for many files. Actually, I'm not quite sure how SVN will behave if someone commits a file with the same location and name as one that is ignored on another local copy which updates. BizarroAzrael fucked around with this message at 10:23 on Oct 8, 2009 |
|
#
¿
Oct 8, 2009 09:45
|
|
|
Doc Block posted:So then why are you going out of your way to not version local copies of versioned files? Example I've been given is that someone moves a new file to a build machine for testing, so the conflict occurs after committing it on either machine if it's not removed from the other. Though I believe we have also had people separately create files in the same location and name and create a conflict when one commits it. I'm trying to make a script that will use SVN diff to get a list of files committed between the last update and the new one, but I have checked and found that some of the files added between the version number I give it are left out. Can anyone explain this? Edit: SVN log -v -r [version]:[version] looks hopeful. BizarroAzrael fucked around with this message at 16:46 on Oct 8, 2009 |
|
#
¿
Oct 8, 2009 16:36
|
|
|
Triple Tech posted:Can't you run a soft update and get the list of files that way? As far as I know, you can only get a lsit of files like that through tortoise, not the command line level I need to make scripts for. A lot of people require an up-to-date build very frequently. It is possible to apply a local change and do a partial rebuild to implement it in the local copy, but that requires a complete build to have been done if you don't want to build the whole thing. We want an update a build run every night with local changes preserved. If local changes result in a bugged build they can either be reverted or the backup can be used later.
|
|
#
¿
Oct 8, 2009 17:56
|
|
|
A team here have a recurring problem with SVN automatically merging files during the overnight update and breaking the subsequent attempt to build the code. I wanted to pitch the solution to you guys: Detect files that will be merged using svn status -u Rename those files svn update normally, replacing the moves files Run the build process, which will use the new version of the files from the server rather than the locally changed one Possibly copy the local copy of the file back Record all this in a log file for the user, allowing them to merge the files by hand Sound alright?
|
|
#
¿
Nov 9, 2009 16:00
|
|
|
Munkeymon posted:Just so you know, if you run the update using --diff3-cmd thisisnotaprogram, it will simply replace everything it was going to merge (because by giving it a junk command to run you have effectively broken that feature). I don't know if this will help you, but I thought it might. Sorry, accidentally unbookmarked the thread. That sounds useful, so I just pass any bullshit there as an argument and it will stop merging? I'm looking at removing a versioned directory (which, if it matters, has versioned contents inside it) but it may contain unversioned files on other computers. What becomes of those files? Or does it create a conflict and kill the update?
|
|
#
¿
Nov 19, 2009 18:17
|
|
|
Munkeymon posted:That's been my experience on Windows and OSX from at least 1.4.something up to relatively current builds - I haven't had to do it in at least a few months. Relying on it does make me a little nervous because I bet they could change the behavior to throw an error and end the operation if they really wanted, but if they do I hope they add a 'stomp on changes' flag. Also keep in mind that the diff only happens when SVN feels the need to merge things - it won't just stomp on any file newer than the repo copy, but at least it won't try to merge anything. May have found a solution that means I won' have to delete the directory, so that's alright. Since testing it involves committing such a change I probably won't test it just to satisfy curiosity. I do still have a problem with conflicts between unversioned files on working copies and versioned stuff on the server killing updates. Really I want the local stuff to remain without stopping the rest of the update. I can use status -u to find conflict files ahead of time, or get them from update error messages, but is there a way to exclude files from the update? So I can tell SVN to update a whole directory but exclude certain files so the conflict doesn't happen.
|
|
#
¿
Nov 24, 2009 18:45
|
|
|
Someone seems to have had a hiccup after merging back to the SVN trunk version after previously being on a branch, so now some portions of their working copy are still on the branch. Can anyone suggest how best to deal with this? Apparently it's caused by a bug in the Switch function.
|
|
#
¿
Jan 28, 2010 17:05
|
|
|
Has anyone ever made C# apps to deal with SVN. I'm making something to deal with the above issue with part of a working copy being pointed at a branch. The idea is you run the app and it tells you what URL every directory is pointed at. Problem is that it wastes a lot of time trying to SVN info on unversioned directories or stuff in the .SVN folders. Is there a good, quick way that C# can determine if a directory is versioned or now?
|
|
#
¿
Feb 2, 2010 16:44
|
|
|
So has anyone encountered this problem SVN seems to have with switching sometimes that leaves a working copy sometimes partially pointed at the wrong branch/trunk? Is there a good way to easily detect this occurring and set it straight? Right now I'm trying to make a batch script that svn info queries each directory for their URL, but it seems to fall over without checking the whole working copy for some reason.
|
|
#
¿
Feb 10, 2010 16:39
|
|
|
I get the following at the beginning of some lines of the output from SVN status:code:
|
|
#
¿
Feb 24, 2010 14:06
|
|
|
I'm trying to fix a working copy on a guys PC and the Tortoise SVN overlays indicating if something has a local change/conflict ect only appear on directory icons, not individual files, but I can't seem to find an option that would do this, any idea what's going on?
|
|
#
¿
Mar 9, 2010 15:43
|
|
|
gently caress. Just switched to newest SVN, which seems to create a new problem when updating. I run svn from the command line and it wants user input every time it finds a file in conflict. I want it to leave the local changes alone and move on with the update without input, is that svn update --non-interactive?
|
|
#
¿
Mar 23, 2010 11:10
|
|
|
musclecoder posted:It should show you a list of options like (df) diff-full, (tf) theirs-full, (mf) mine-full and (i) ignore (or something like that, I'm going off memory). Just type "i" or whatever the option is for "deal with this later." This update takes place overnight, as part of a larger process, so it needs to be automated. Might not be as bad as I thought though, it seems to do merges fine in the tests I've done, so it's a handful of exceptions. And it deals with unversioned files blocking versioned ones, which I used to have to work around.
|
|
#
¿
Mar 23, 2010 12:07
|
|
|
Problem: Error: Checksum mismatch while updating Error: '[filename]'; expected: Error: '71467c5d444b7e4869609f5993ad077b', actual: '0b590ed77b36a502b78885db58340307' Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout. Cleanup on the whole project didn't make a difference, and a new checkout is undesirable, can anyone tell me what happened here? The prior update stopped when it couldn't move a temp file over an existing one. The .tmp was left in the directory, though I don't know where it came from and why it wasn't coming from the repository. Would deleting the offending directory and doing an SVN update to restore it sort it out?
|
|
#
¿
Mar 25, 2010 11:40
|
|
|
I'm getting lots of failed svn updates when there is a file on the repository and one by the same name on the working copy. I thought this issue was dealt with in 1.6.5, and even tested it, but it's still happening. Maybe it's unable to merge the filetypes in question, but it should still deal with that. Can anyone suggest what I need to do to make SVN work in spite of itself? Do I need to script something to move the files out of the way on the working copy side again?
|
|
#
¿
Apr 15, 2010 09:30
|
|
|
Came by a strange occurrence in SVN just now, I ran svn status -u [working directory] and got a warning back about an "illegal repository URL ''". I thought it would be getting the URL from the .SVN folder in the directory, but svn update and svn info both worked without issue. Does anyone know what's going on? Svn status is part of a script I need working.
|
|
#
¿
May 26, 2010 09:47
|
|
|
Is there an easy way to find out what version a repository was at at a given time on the command line? Say I wanted to update to the version for 4PM every day? Would I need to do an SVN log on the project and use a FIND command to get the last commit revision before that time? Or is there some existing function to do it?
|
|
#
¿
Jun 9, 2010 17:46
|
|
|
Mine GO BOOM posted:svn up -r "{`date '+%Y-%m-%d 16:00:00'`}" Sorry, it says there's a syntax error, and I've not been able to find another example.
|
|
#
¿
Jun 10, 2010 13:40
|
|
|
molinari posted:I don't use subversion, but check out this section about revision dates in the subversion book. It lists all valid date formats. It seems you should swap the quotes and curly brackets, then Mine GO BOOM's suggestion should work. Got distracted and had to down tools for a bit, but this is exactly what I need, thanks.
|
|
#
¿
Jun 22, 2010 16:22
|
|
|
I have a few people that are finding SVN "skips" on updating a certain folder in their working copy. You can update the contents fine, but an attempt to update on the directory just gets a "skipped" message. I've taken a look and the .svn directory is still there. Does anyone know what's going on?
|
|
#
¿
Jun 29, 2010 10:07
|
|
|
I'm checking some stuff out over SVN and it's crazy slow. Tortoise window says 0kbps most of the time, spiking up every now and then. In about 2 hours I've got about 100MB. I've got a tech guy looking at the server and network side, but is there anything I could do that might help? I wonder if it's something concerning the repository, because I've been getting stuff from another repository without any problems.
|
|
#
¿
Sep 1, 2010 11:31
|
|
|
BizarroAzrael posted:I'm checking some stuff out over SVN and it's crazy slow. Tortoise window says 0kbps most of the time, spiking up every now and then. In about 2 hours I've got about 100MB. I've got a tech guy looking at the server and network side, but is there anything I could do that might help? I wonder if it's something concerning the repository, because I've been getting stuff from another repository without any problems. To follow up on this, I've had a new hard drive installed but it performs the same. I've also done the same checkout on a different machine and it's much quicker, though it also seems to slow down on larger directories. I don't think my network connection is slower or anything, could it be anything else?
|
|
#
¿
Sep 15, 2010 16:43
|
|
|
BizarroAzrael posted:To follow up on this, I've had a new hard drive installed but it performs the same. I've also done the same checkout on a different machine and it's much quicker, though it also seems to slow down on larger directories. I don't think my network connection is slower or anything, could it be anything else? In case I'm not talking to myself, I think the issue is just massive directories of thousands of large files, network usage is very low and spikes to fetch a file every now and then. Seems to be an SVN issue. To get around this, I thought I might make a script to deal with this by breaking the checkout down into lots of small checkouts/updates of single files. Here's what I had in mind: 1. Checkout just the empty root directory of the project. 2. run "svn list -r [file]" on the new project directory to populate a list of files that I will want. 3. For each file in this list, run "svn update --depth empty [file]" However, I've done some experimenting and if I create a versioned directory in this way and then attempt a normal update on it, it won't pick up the missing files that should be inside. I can put them in with their own separate updates, but I think this means I will have a checkout that can not receive any new files from the repository. Is there some solution to this, is this idea workable?
|
|
#
¿
Sep 16, 2010 17:48
|
|
|
sonic bed head posted:How big is what you are trying to check out? Are you talking gigabytes? I've checked out up to about 4GB before and it's never been too much of a problem. Have you tried using the command line instead of tortoise and seeing what happens? 4-6GB I think, not including the .svn directory, over 11,000 files as I recall. These are uncompressed sound files by the way, not text or code.
|
|
#
¿
Sep 17, 2010 00:39
|
|
|
I actually did a Robocopy from another copy on another machine, which seemed to go fine. Will this be alright for things like commits, or will it identify me as the person I copied it from? Might this be a better solution than a normal checkout?
|
|
#
¿
Sep 17, 2010 11:23
|
|
|
sonic bed head posted:As long as you also copied the .svn directories, it is exactly the same as a checkout. SVN isn't really built for tons of binary files like that. This might help. Late response but thanks for that. So if I robocopy one SVN working copy(A) into another(B), and do an update on B, SVN will update the contents of A as well?
|
|
#
¿
Oct 1, 2010 10:19
|
|
|
What's the difference between svn update failures from conflicts and "skipped" files and directories? Got a guy who has files marked as in conflict which were "skipped" and SVN doesn't bother to update the remainder of the directory they were in. Why doesn't svn just ignore these files and keep going? It's caused big holes in the update.
|
|
#
¿
Oct 6, 2010 12:43
|
|
|
|
| # ¿ Apr 29, 2024 10:22 |
|
|
I'm finding a number of checkout are having their cleanups/updates fail because files that have been versioned and present on the machine for a long while are coming up as no longer versioned. Deleting the offending file brings up the same error complaining of the now missing file, so I had to delete the parent directory and restore it with an update. Does anyone know what's going on? Also, say the project auto-generates files, so the same unversioned files are on many machines, and then one of those files was committed. Is there anything that can be done short of detecting the conflict ahead of time and removing the file, to stop this killing attempted updates? Is there a recommended procedure, perhaps something the person committing the file should do?
|
|
#
¿
Nov 1, 2010 11:12
|
|