The problem with this case is that it is the textbook example of the think about the children argument to bypass regular civil rights.
How is that a problem? It's a question that needed to be asked. I would consider the justice system broken if it didnt ATTEMPT it.
More importantly, this is bad case law for privacy. The evidence was likely incriminating. If privacy existed in such a manner, then the fact that it's technically im/possible to obtain information should be moot. Either it's legal or not to pursue it. Now it's unlikely that all search and seizure will be overturned (which are simply extensions of a legal precedent about investigation), but much more likely that this case will be ignored in the future.
What's worse is you should ask yourself the question, what if this case was simply a person UNRELATED to a case, who would not release a key to information that would empirically prove who a serial killer was? Is this really a good thing? I would think that was criminal. I think this decision is only applicable when the evidence might be incriminating, not in any other situation.//civil libertarian, what do I know.
It's not illegal for him to solicit donations from out of state, but that doesn't make it moral.
The fact it isn't illegal doesn't make it moral or immoral excepting that a choice to run implies a commitment to represent views and committing an illegal act forfeits the entirety of the effort, resulting in net fraud. That's the immorality I was referencing. Many people's arguments won't make sense to you when you don't have an understanding of moral basics (and their different flavors).
That doesn't even make sense. According to the comic and the Pew Institute study it cites, the candidate that spends more on advertising wins.
So it's morally diligent to his constituents, to obtain funding in the most efficient ways possible without introducing campaign promises to larger donors that may run contrary or alter his constituent's stances.
Basically, his policies couldn't stand on their own, so he decided to cheat.
Thank you for restating your and the GP's premise, both entirely without any supporting reasoning. You just stated that policies don't matter, money matters. Try to keep up.
The people in these positions should represent those in their districts, not those from other places (like affluent Silicon Valley where I live).
I'm not sure where the relativistic logic is in this "stance".
The moral corruption is that money is an overriding lever for political success, not the source(s). In the winner-takes-all, money-makes-the-campaign, incumbant-safety-through-populace-lethargy, there's nothing immoral about an intelligent representative gathering funds by any means necessary (that doesn't suicide on illegality). There is LESS influence on policy by a non-constituent populist micro donation system, making it the true "lesser of two evils" in campaign funding.
To be fair, selling Apple off piecemeal would have been the right decision. The Jobs-Apple machine has completely replaced everything from that period (and earlier) from product line to store layout. The branding of Apple hurt iPod sales in 2001 but whatever branding was on it would have done just as well in the long run due to their new product lines. The success of the iPod's interface is largely the result of a contracted company called Pixo that any other company could have hired (as long as they had Jobs to direct). See wikipedia:iPod. But that's just my opinion.
With eight years of legacy code out there, it is likely that there are going to be a fairly large number of systems that will not migrate to PHP 5 in the near future, and a reasonable proportion of those that will not make the migration at all.
I question the validity of these assumptions. My first salaried job was programming PHP/FI 2 (1998). I cannot find a single product I have been involved with or even used in the past (which contains PHP code), that hasn't upgraded. Systems written in PHP could only benefit from the improvements in 5 and there's almost nothing written in PHP that's so critical* that it wouldn't be upgraded by the current developers or new developers trained in 5.
*This is both a side effect of the language design and the people who write it.
Can someone give some examples of products stuck in 4.0?
Unsurprisingly, the press release does not refer to a DMCA complaint, only a criminal complaint. They can refer to the DMCA in context, but it does not apply directly.
Email is more complicated than the us postal system. Email is not regulated, controlled, operated by the public. In fact, it's often unclear who controls the email servers since anyone can set them up and use them. Imagine a postal system that any person OR ENTITY (including foreign interests) can set up and operate. That's what we're talking about. You cannot apply the same rules.
I would have gone with Google endangering the public (my family or person) by the invasion and then publishing their obtained pictures. There is no legal difference between this type of photography and taking a picture of my house and publishing it on a billboard (ad campaign) for home security with big block letters that say "Don't leave your property unsecured like this." There is a reason they are throwing up privacy, it's because they are trying to frame the case in a way that gives them a leg to stand on.
I have a personal trainer 3-5 times a week for an hour, and a ball at home for cardio on the weekends. I found that I didn't get committed until I started spending money for it. It's important to understand your physical and psychological needs to engage in a workout plan.
I have a synthetic aortic valve and ran for a very long time after my second aortic surgery at age 9. I was not allowed to play contact sports for fear of a clot traveling to the valve. By age 12 I had blown a knee. By age 20 I had blown out my back doing physical labor. Now into my 30's I do weight training. My blood pressure maxes out and I reach up into 190 beats per minute for about 45 minutes with 5 minute warmups and 10 minute cooldowns. The cardio that you get from pushing weights is no worse or better than full elliptical cardio if you have the endurance. Your heart doesn't know the difference and you are simply working different muscles more intensely (depending on your routine). I use a large ball to do gravity cardio during the weekends for 30 min/day. The biggest problem with my weight training is a specific diet and routine that must be maintained or I will end up vomiting after the lifting workouts due to decreased bloodflow (synthetic valve) leading to my body reacting to exhaustion as trauma. If you start working out hard enough, your body will react similarly for a time until your nutrition and vascular system catches up.
Will this work on searchs or if you trac-link from a wiki page or ticket?
This will prevent someone without adequate perms from accessing a page result, from a search. I don't think it applies to search results per se. It will prevent someone without adequate perms from accessing a page linked from a wiki.
For ACL to source, you can use SVN perms via trac.ini, authz_module_name if your authz_file contains permissions which are project named. Some people like me, are sometimes found using (Apache) Location directives before figuring this out.
The fact that Javascript is widely used for browser scripting does not mean that Javascript can only be used to do browser scripting.
I understand that. I don't see why that matters. To whit:
The author states that the necessary equipment for writing JavaScript programs is a browser and a text editor.
The original quote makes no mention of serverside scripting, it makes mention of a browser. Therefore any reference to javascript is assumed to be executed within a browser. The points summarized were:
The article makes a bad assumption about needing 1 browser.
Response, 1 browser is insufficient nowadays.
Response, you dont have to use more than 1 browser if you use an OO library and you need more than 1 browser only if you're making a website.
My response, you'd have to be an idiot to believe that since the OO library has browser-specific implementations that may or may not be equal and if you're going to be literal about only needing 1 browser to write javascript (which you arent even doing anymore if you only use an api), then you dont need a browser at all for javascript or a website. Javascript requires knowledge of a browser's DOM implementation to display anything.
Your response, you don't need a browser for serverside javascript or for displaying anything using javascript.
I concede your point, since it has nothing to do with what I was talking about.
You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website.
This is a red herring as webites are not the topic and theoretically you don't need a browser to develop a website at all. Simplest: yum install apache. Done. If you are going to take the comment out of context, be consistent.
Actually, there are very few incompatibilities between JavaScript implementations. It's the DOM that is the cause of most incompatibilities, and all the major libraries like jQuery, Prototype, etc, abstract those difficulties away.
To display anything at all with javascript requires you to reference the DOM means that they are effectively parts of the same problem. Attacking the language as opposed to acknowledging the known problem seems to be your goal. Are you really implying that because someone else has written browser specific routines, that the OP's point:
There are still so many cross-browser incompatibilities with javascript today you pretty much have to write one script for firefox and one for IE each time you code.
is incorrect?
Way to support his argument and make yourself look like an idiot. God forbid you want to use more than the Library's features or you'll have to ACTUALLY WRITE JAVASCRIPT which means you'll have to do multiple browser specific implementations (in almost all cases) and still have to stamp the site with "works best on..."
Might want to check the source of the/. page you're reading before you spout about obsoletion of browser specific javascript.
IDE does not imply 1 application. Integrated Development Environment is rarely a single binary (regardless of what wikipedia would have the world believe). In retrospect, I have wrongly made an assumption that others understood a modular application != IDE, in part, because of my examples listed.
What you think is shitty and what I think is shitty are two different things.
Unless you can provide an example of 2 IDEs that are equally productive in every way but developer preference and I'll show you why you're not plainly trolling.
1)Trac integrates 1 repository per trac. While I can configure SVN to use single configs for multiple repositories, this does not translate for Trac. This means I have to set up users and permissions for every person (involved) per project which is extra work or put all my projects under a single repository, which is bad. Have not tried Trac with CVS:p
2)Attributing SVN commits based on tagged commit comments. JIRA does this and it rocks.
3)No approval mechanism or role-based approval. If I can't change a defect ticket status, I can't change ANY ticket status as opposed to ones I've created (tasks) or one of my team has created unless I have permission to change all ticket statuses. Blanket permissions are the sole way to manage tiers of review in trac and you need complex project processes to make that work at all.
4)The interface is not modular enough. Lots of things in the interface are clean, tickets are not one of them as they attempt to inject concepts your project may not have. Version, keywords, priority, cc, unbound Assign-To. *THIS IS NO LONGER AN ISSUE see:Hiding Fields and Adding Custom Fields + TracTicketsCustomFields*
5)The interface is not mature enough. Where's the simple integration of trac-user/group to email to ticket? There is no concept of Trac group AFAIK.
of course, my lack of experience with trac as an issue-tracker in the last year may mean I have neglected to keep up on new trac offerings. see #4, and this is just my off-the-cuff list. I'm sure there's a couple more issues but JIRA's working well for us.
I would LOVE to use trac for everything, but not yet.
there's no need for everyone to use your choice of shitty IDE
If there's evidence the IDE is "shitty", everyone should switch to a non-"shitty" one. There is no "my IDE" nor is there a place for personal preference over productivity in a project unless you are a masochist.
Everyone gets by using whatever 'IDE' that they want. The IDE does nothing except provide them an editor.
An editor and an IDE are completely different animals. If your IDE does not have an integrated version (or a broken or functionally different integration) of the VCS, you lose productivity and create problems down the line. When you have disparate IDEs and you want to add to the java path for a certain project and you show how to do it in one IDE, you lose productivity if someone else isn't familiar with what that is or how to do it in their IDE. The fact of the matter is that standardizing IDEs is assumed in any project over 3 people. Theoretically it all should be the same per project, but try using the Flex plugin for versus the Flex Builder and you have a recipe for wasted time. Lemme know how long it's going to take you to deploy Tomcat in Emacs for your localdev because in Eclipse it's trivial. I suspect you have a mixing of projects if you are using disparate IDEs. If you are working on standalone backend, that's a different project and a different IDE, but everyone on that project will be using the same tools over time.
How about the backing storage? If shit happens, I'd rather try to recover from text files than binary chunks
You are correct that a text-storage would make recovery easier, although I have doubts that it's at all possible to recover from the Berkley DB in most cases. My question is what kind of failure partially damages a repository that you want to recover whatever part of it you can? I assume a hardware failure. SVN stores text files, binary files, directories. A text recovery for these things would never really be possible anyways. The only way to recover such data would be from a backup regardless of the version control method. SVN is backed up by simply zipping the directory and putting a copy somewhere. I do this daily & weekly. This is how recovery is usually done which is indifferent to filetype. This same approach is done with CVS but causes some serious issues when trying to get everyone back on a restored copy.
Why would we want granular access to text files in storage? If 'recovery' is high enough on the list to warrant "the primary reason", your revision control needs to have access to the backend storage, the system must have a high failure rate and I would tag it unreliable. I don't know of a reason to want access to the backend storage directly. If SVN were somehow aberrant in this regard, I would admit it, but there are lots of utilities that do not have flatfile backends and it only seems to be an issue with revision control. Sourcesafe, GIT/Bazaar with its hashed key/values or god forbid its crypto hashes, means you can't access their files directly either. Is it really assumed to be a good thing?
I believe the point of version control is to track all changes, regardless of intent (bad commits count). This does not speak to anything else including recoverability method. I find it mildly disturbing that you can or would alter the history in CVS. In SVN you basically have to dump the entire repository history to make a change to the history. The number of times I've had to restore an SVN backup is 1. That was to do a test of the integrity of the zipped repository over the last 3 years, 12 repositories and near 10000 commits. SVN is stable enough for me.
In the case where you want or need the peace of mind to be able to alter the "backend storage", I hope you have a long and prosperous career with CVS. We just have different goals.
Whenever I have a project at work or at home, I expect some basic things.
1. Standardized IDE. Everyone use the same thing and you will be able to do builds, deployments, and fix bugs quicker. Eclipse/Zend/VC++ whatever. 2. Communication channels. Email addresses of everyone. A group email that goes out to all teammembers is helpful. IM of everyone - Trillian, GAIM, I don't care. 3. Version control. SVN for me. 4. Project/Task/Issue/Bug tracking. I use SVN integrated with Trac at home. It's not very good compared to commercial offerings, but it works. 5. Standardized build and deployment. ANT/Bash scripts/whatever 6. Basic development practices (test/commit often), QA methodology/granularity. The more experience you have, the better you get at this.
I like to have 2-4 deployments. Production, QA - daily build via cron, Dev - build of latest commit via svn hook, and LocalDev - complete build on each developer's machine(s) pre-commit. When QA+Product Owner(s) sign off, move from QA to production as a release. This is "best case" and often you have to compromise based on necessity or need. This means up to 4 different builds and deployments, although QA and Production should be near-identical.
Slashdot Mirror
How is that a problem? It's a question that needed to be asked. I would consider the justice system broken if it didnt ATTEMPT it.
More importantly, this is bad case law for privacy. The evidence was likely incriminating. If privacy existed in such a manner, then the fact that it's technically im/possible to obtain information should be moot. Either it's legal or not to pursue it. Now it's unlikely that all search and seizure will be overturned (which are simply extensions of a legal precedent about investigation), but much more likely that this case will be ignored in the future.
What's worse is you should ask yourself the question, what if this case was simply a person UNRELATED to a case, who would not release a key to information that would empirically prove who a serial killer was? Is this really a good thing? I would think that was criminal. I think this decision is only applicable when the evidence might be incriminating, not in any other situation. //civil libertarian, what do I know.
Oh well, I guess people still haven't learnt that the old ways of copyright are only hanging on through inertia.
This.
The fact it isn't illegal doesn't make it moral or immoral excepting that a choice to run implies a commitment to represent views and committing an illegal act forfeits the entirety of the effort, resulting in net fraud. That's the immorality I was referencing. Many people's arguments won't make sense to you when you don't have an understanding of moral basics (and their different flavors).
So it's morally diligent to his constituents, to obtain funding in the most efficient ways possible without introducing campaign promises to larger donors that may run contrary or alter his constituent's stances.
Thank you for restating your and the GP's premise, both entirely without any supporting reasoning. You just stated that policies don't matter, money matters. Try to keep up.
I'm not sure where the relativistic logic is in this "stance".
The moral corruption is that money is an overriding lever for political success, not the source(s). In the winner-takes-all, money-makes-the-campaign, incumbant-safety-through-populace-lethargy, there's nothing immoral about an intelligent representative gathering funds by any means necessary (that doesn't suicide on illegality). There is LESS influence on policy by a non-constituent populist micro donation system, making it the true "lesser of two evils" in campaign funding.
To be fair, selling Apple off piecemeal would have been the right decision. The Jobs-Apple machine has completely replaced everything from that period (and earlier) from product line to store layout. The branding of Apple hurt iPod sales in 2001 but whatever branding was on it would have done just as well in the long run due to their new product lines. The success of the iPod's interface is largely the result of a contracted company called Pixo that any other company could have hired (as long as they had Jobs to direct). See wikipedia:iPod. But that's just my opinion.
I question the validity of these assumptions. My first salaried job was programming PHP/FI 2 (1998). I cannot find a single product I have been involved with or even used in the past (which contains PHP code), that hasn't upgraded. Systems written in PHP could only benefit from the improvements in 5 and there's almost nothing written in PHP that's so critical* that it wouldn't be upgraded by the current developers or new developers trained in 5.
*This is both a side effect of the language design and the people who write it.
Can someone give some examples of products stuck in 4.0?
This is Quirk's Exception. boo.
Unsurprisingly, the press release does not refer to a DMCA complaint, only a criminal complaint. They can refer to the DMCA in context, but it does not apply directly.
Email is more complicated than the us postal system. Email is not regulated, controlled, operated by the public. In fact, it's often unclear who controls the email servers since anyone can set them up and use them. Imagine a postal system that any person OR ENTITY (including foreign interests) can set up and operate. That's what we're talking about. You cannot apply the same rules.
How do you rule on how someone licenses their own code? Is there some precedent?
I would have gone with Google endangering the public (my family or person) by the invasion and then publishing their obtained pictures. There is no legal difference between this type of photography and taking a picture of my house and publishing it on a billboard (ad campaign) for home security with big block letters that say "Don't leave your property unsecured like this." There is a reason they are throwing up privacy, it's because they are trying to frame the case in a way that gives them a leg to stand on.
I have a personal trainer 3-5 times a week for an hour, and a ball at home for cardio on the weekends. I found that I didn't get committed until I started spending money for it. It's important to understand your physical and psychological needs to engage in a workout plan.
I have a synthetic aortic valve and ran for a very long time after my second aortic surgery at age 9. I was not allowed to play contact sports for fear of a clot traveling to the valve. By age 12 I had blown a knee. By age 20 I had blown out my back doing physical labor. Now into my 30's I do weight training. My blood pressure maxes out and I reach up into 190 beats per minute for about 45 minutes with 5 minute warmups and 10 minute cooldowns. The cardio that you get from pushing weights is no worse or better than full elliptical cardio if you have the endurance. Your heart doesn't know the difference and you are simply working different muscles more intensely (depending on your routine). I use a large ball to do gravity cardio during the weekends for 30 min/day. The biggest problem with my weight training is a specific diet and routine that must be maintained or I will end up vomiting after the lifting workouts due to decreased bloodflow (synthetic valve) leading to my body reacting to exhaustion as trauma. If you start working out hard enough, your body will react similarly for a time until your nutrition and vascular system catches up.
This will prevent someone without adequate perms from accessing a page result, from a search. I don't think it applies to search results per se. It will prevent someone without adequate perms from accessing a page linked from a wiki.
To clarify, there are no real ACLs for tickets.
For ACL to source, you can use SVN perms via trac.ini, authz_module_name if your authz_file contains permissions which are project named. Some people like me, are sometimes found using (Apache) Location directives before figuring this out.
(authz_file contains) ...
[calc:/branches/calc/bug-142]
harry = rw
sally = r
(trac.ini contains)
authz_module_name = calc
Trac now recognizes ACLs the same as SVN does.
I understand that. I don't see why that matters. To whit:
The original quote makes no mention of serverside scripting, it makes mention of a browser. Therefore any reference to javascript is assumed to be executed within a browser. The points summarized were:
The article makes a bad assumption about needing 1 browser.
Response, 1 browser is insufficient nowadays.
Response, you dont have to use more than 1 browser if you use an OO library and you need more than 1 browser only if you're making a website.
My response, you'd have to be an idiot to believe that since the OO library has browser-specific implementations that may or may not be equal and if you're going to be literal about only needing 1 browser to write javascript (which you arent even doing anymore if you only use an api), then you dont need a browser at all for javascript or a website. Javascript requires knowledge of a browser's DOM implementation to display anything.
Your response, you don't need a browser for serverside javascript or for displaying anything using javascript.
I concede your point, since it has nothing to do with what I was talking about.
This is a red herring as webites are not the topic and theoretically you don't need a browser to develop a website at all. Simplest: yum install apache. Done. If you are going to take the comment out of context, be consistent.
To display anything at all with javascript requires you to reference the DOM means that they are effectively parts of the same problem. Attacking the language as opposed to acknowledging the known problem seems to be your goal. Are you really implying that because someone else has written browser specific routines, that the OP's point:
is incorrect?
Way to support his argument and make yourself look like an idiot. God forbid you want to use more than the Library's features or you'll have to ACTUALLY WRITE JAVASCRIPT which means you'll have to do multiple browser specific implementations (in almost all cases) and still have to stamp the site with "works best on..."
Might want to check the source of the /. page you're reading before you spout about obsoletion of browser specific javascript.
Not to be ridiculously picky, but (generic) nails, (generic) screws, and (generic) fasteners are not patented.
IDE does not imply 1 application. Integrated Development Environment is rarely a single binary (regardless of what wikipedia would have the world believe). In retrospect, I have wrongly made an assumption that others understood a modular application != IDE, in part, because of my examples listed.
Unless you can provide an example of 2 IDEs that are equally productive in every way but developer preference and I'll show you why you're not plainly trolling.
1)Trac integrates 1 repository per trac. While I can configure SVN to use single configs for multiple repositories, this does not translate for Trac. This means I have to set up users and permissions for every person (involved) per project which is extra work or put all my projects under a single repository, which is bad. Have not tried Trac with CVS :p
2)Attributing SVN commits based on tagged commit comments. JIRA does this and it rocks.
3)No approval mechanism or role-based approval. If I can't change a defect ticket status, I can't change ANY ticket status as opposed to ones I've created (tasks) or one of my team has created unless I have permission to change all ticket statuses. Blanket permissions are the sole way to manage tiers of review in trac and you need complex project processes to make that work at all.
4)The interface is not modular enough. Lots of things in the interface are clean, tickets are not one of them as they attempt to inject concepts your project may not have. Version, keywords, priority, cc, unbound Assign-To.
*THIS IS NO LONGER AN ISSUE see:Hiding Fields and Adding Custom Fields + TracTicketsCustomFields*
5)The interface is not mature enough. Where's the simple integration of trac-user/group to email to ticket? There is no concept of Trac group AFAIK.
of course, my lack of experience with trac as an issue-tracker in the last year may mean I have neglected to keep up on new trac offerings. see #4, and this is just my off-the-cuff list. I'm sure there's a couple more issues but JIRA's working well for us.
I would LOVE to use trac for everything, but not yet.
If there's evidence the IDE is "shitty", everyone should switch to a non-"shitty" one.
There is no "my IDE" nor is there a place for personal preference over productivity in a project unless you are a masochist.
An editor and an IDE are completely different animals. If your IDE does not have an integrated version (or a broken or functionally different integration) of the VCS, you lose productivity and create problems down the line. When you have disparate IDEs and you want to add to the java path for a certain project and you show how to do it in one IDE, you lose productivity if someone else isn't familiar with what that is or how to do it in their IDE. The fact of the matter is that standardizing IDEs is assumed in any project over 3 people. Theoretically it all should be the same per project, but try using the Flex plugin for versus the Flex Builder and you have a recipe for wasted time. Lemme know how long it's going to take you to deploy Tomcat in Emacs for your localdev because in Eclipse it's trivial. I suspect you have a mixing of projects if you are using disparate IDEs. If you are working on standalone backend, that's a different project and a different IDE, but everyone on that project will be using the same tools over time.
You are correct that a text-storage would make recovery easier, although I have doubts that it's at all possible to recover from the Berkley DB in most cases. My question is what kind of failure partially damages a repository that you want to recover whatever part of it you can? I assume a hardware failure. SVN stores text files, binary files, directories. A text recovery for these things would never really be possible anyways. The only way to recover such data would be from a backup regardless of the version control method. SVN is backed up by simply zipping the directory and putting a copy somewhere. I do this daily & weekly. This is how recovery is usually done which is indifferent to filetype. This same approach is done with CVS but causes some serious issues when trying to get everyone back on a restored copy.
Why would we want granular access to text files in storage? If 'recovery' is high enough on the list to warrant "the primary reason", your revision control needs to have access to the backend storage, the system must have a high failure rate and I would tag it unreliable. I don't know of a reason to want access to the backend storage directly. If SVN were somehow aberrant in this regard, I would admit it, but there are lots of utilities that do not have flatfile backends and it only seems to be an issue with revision control. Sourcesafe, GIT/Bazaar with its hashed key/values or god forbid its crypto hashes, means you can't access their files directly either. Is it really assumed to be a good thing?
I believe the point of version control is to track all changes, regardless of intent (bad commits count). This does not speak to anything else including recoverability method. I find it mildly disturbing that you can or would alter the history in CVS. In SVN you basically have to dump the entire repository history to make a change to the history. The number of times I've had to restore an SVN backup is 1. That was to do a test of the integrity of the zipped repository over the last 3 years, 12 repositories and near 10000 commits. SVN is stable enough for me.
In the case where you want or need the peace of mind to be able to alter the "backend storage", I hope you have a long and prosperous career with CVS. We just have different goals.
Whenever I have a project at work or at home, I expect some basic things.
1. Standardized IDE. Everyone use the same thing and you will be able to do builds, deployments, and fix bugs quicker. Eclipse/Zend/VC++ whatever.
2. Communication channels. Email addresses of everyone. A group email that goes out to all teammembers is helpful. IM of everyone - Trillian, GAIM, I don't care.
3. Version control. SVN for me.
4. Project/Task/Issue/Bug tracking. I use SVN integrated with Trac at home. It's not very good compared to commercial offerings, but it works.
5. Standardized build and deployment. ANT/Bash scripts/whatever
6. Basic development practices (test/commit often), QA methodology/granularity. The more experience you have, the better you get at this.
I like to have 2-4 deployments. Production, QA - daily build via cron, Dev - build of latest commit via svn hook, and LocalDev - complete build on each developer's machine(s) pre-commit. When QA+Product Owner(s) sign off, move from QA to production as a release. This is "best case" and often you have to compromise based on necessity or need. This means up to 4 different builds and deployments, although QA and Production should be near-identical.
a single svn move (Rename) from the middle of a directory tree can corrupt an svndump so that svn wont import it. use svnsync now.