|
P.P.S.: using svn copy on URLs implicitely commits the change whereas the version you used still required a commit. You did perform the move efore the commit, so there is a distinct difference between the command sequence that worked for me and yours. Maybe there is a bug: Older versions of the TSVN documentation specifically pointed out that you should commit all local changes before performing a move, because SVN couldn't keep track of the chronological correct order of either change, and thus could mess up the results. I am not sure whether or not the same holds true, but the fact that you didn't arrive at the expected results seems to indicate it still does!
|
|
|
|
|
Please tell us you are not using the file:/// protocol...
I have been using Subversion of years. I have run into problems but nothing like you describe. And trust me, we get file conflicts all the time.
|
|
|
|
|
The whole point of version control is to prevent developers from overwriting other developers' source code. Subversion is a complete joke and handling branching and merging is a total nightmare. Simple solution: convert over to an intuitive SCM like git. Once you learn it, all the other solutions become stupid and irrelevant. Ask Linus if you don't believe me. 
"God gave us two ears and one mouth to remind us we should listen twice as much as we talk." - Author unknown
|
|
|
|
|
Git might be wonderful but intuitive it is not.
|
|
|
|
|
EdReel wrote: intuitive SCM like git
That's an oxymoron if I've ever seen one 
Branches and merging used to be tricky and sometimes painful in older versions of SVN, but since version 1.5 it has improved considerably. If you think it is a nightmare, you haven't looked in the right place or at the right version.
|
|
|
|
|
Did you try having WinMerge as a Merge Tool? That helps resolving quite easily.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
|
The merge can be really painful, especially when you try to stop it after starting. Suddenly your application can have tons of errors because of the extra lines put into the file by the tool.
|
|
|
|
|
I'm implementing USB firmware in a device we are making.
I asked in THIS PLACE[^] (Design And Architecture) based on guessing what the desired topics are for a given forum.
I'm putting USB capability into the firmware of a device we are making.
|
|
|
|
|
|
I've also recently been looking at creating USB firmware. What processor are you using, out of curiosity?
Also, I don't think you'll find many people with that sort of knowledge here, your best bet is to look on electronics and embedded systems forums.
.-.
|o,o|
,| _\=/_ .-""-.
||/_/_\_\ /[] _ _\
|_/|(_)|\\ _|_o_LII|_
\._. |\_/|"` |_| ==== |_|
|_|_| ||" || ||
|-|-| ||LI o ||
|_|_| ||'----'||
/_/ \_\ /__| |__\
|
|
|
|
|
C-P-User-3 wrote: Design And Architecture
That forum is for application design and application architecture.
|
|
|
|
|
It is a well known good practice to use StringBuilders instead of doing many string concatenations. Yet, I got really impressed when I saw a document telling to replace things like this:
private const string SQL =
"SELECT " +
" ID, " +
" NAME, " +
" BIRTHDAY " +
"FROM " +
" TABLE " +
"WHERE " +
" NAME LIKE @PARAM";
By creating the StringBuilder everytime in the method where the SQL was being used. Maybe I am wrong , but I really believe consts aren't doing bad string concatenations all the time.
|
|
|
|
|
Yeah. The compiler should concatenate all of those together when run. So using a stringbuilder everywhere that was used basically shows the person (people?) that wrote the document had no clue as to what they were talking about.
Basically:
BRAINWAVE/1.0
Status-Code: 404
Status-Text: The requested brain could not be found. It may have been deleted or never installed.
So there.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
I can't find a "Delete brain" button on my head.
Should I remove my ears to find the button?
The quick red ProgramFOX jumps right over the Lazy<Dog>.
modified 19-Apr-13 13:37pm.
|
|
|
|
|
Some of our members use the GinAndTonic() method, which does a delete brain operation as a side effect.
Software Zen: delete this;
|
|
|
|
|
But why would anyone write it like that in the first place??? It's horrible. And let's not even begin to talk about why it should be a stored procedure...
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Simple... "best practices". 
|
|
|
|
|
I see little reason to not use a parametrized query like that. OK, if it is static enough top define a const, there is a small case against storing all your query code in the binary instead of the more accessible DB server, but not much else of a case.
|
|
|
|
|
It's not the end of the world, certainly; my preference is to keep databasey stuff in the database. It's just neater; besides, all those +++ and line breaks: FUGLY!!!
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Yes, he could hide the queries in resources files, not out in public code.
|
|
|
|
|
mark merrens wrote: But why would anyone write it like that in the first place???
How else are you going to code a string which contains SQL? One really long line?
mark merrens wrote: And let's not even begin to talk about why it should be a stored procedure...
Presumably you mean it should be a proc instead. Perhaps. But some procs might be rather long when expressed as a SQL string - so same problem.
|
|
|
|
|
What's wrong with it? I mean, it's simple enough I'd put it on one line, but I don't see anything in principle wrong with putting it on several, and as C# doesn't have multi-line string constants, you have to write it as it is there. Edit: apparently @ strings will let you do multi-line constants.
Making code a stored procedure hides it away from the developer and makes it harder to see. Select queries should almost never be in one because it makes you go and look at the database to find out what the code is doing ... or, to put it another way, those queries are part of the business logic and should be in the code. But I have a somewhat old fashioned view of the database as essentially a minimally intelligent data store.
|
|
|
|
|
I like the database to take that strain: it's what it is there for, after all. And I never, ever put SQL in code: I either use a view or a stored procedure.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Oh yes, I have to agree. Prevents SQL injection attacks.
|
|
|
|
|
Also you can fake multiline strings (in VB.NET, say) with an inline XML document, of which the text is then converted to a string.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
