|
Yes, TSVN does make things easier.
Given that all the commands in the original scenario were issued from inside the right subdirectories (committing from the wrong level in the hierarchy also can have unexpected results if you want to be able to see history or merge things properly, which is probably why your workflow involving completely separate checkouts is to be preferred), my inclination is to agree with you and say the cause of this almost certainly has to do with the fact that the move happened before the file being moved was committed in the first place. A move is equivalent (according to the docs) to a copy and a delete, but if you're deleting something whose addition was never committed in the first place, maybe it somehow winds up skipping the delete, which results in two files being present once you do an update. I would personally tend to think this is actually incorrect behavior, but maybe whoever designed it has a good reason for that. It definitely is something that could very easily surprise users, even long-time users who failed to remember all the actions they took in a single batch prior to committing, so it is easier not to do things this way. As you say, when you do a copy directly from and to the repository, the commit happens implicitly as part of the execution of the command, and then you don't have to worry about it.
|
|
|
|
|
For what its worth I found an old installation of the SVN command line client installed on my system (version 1.6.*something*) and tried to reproduce your results. I got to the cp command, and there I got an error message:
C:\Users\Public\Documents\Entwicklung\Projekte\Sandbox\test_svn_3_1_6\trunk>svn
cp . ../branches/test_branch/
svn: Kann Pfad ».« nicht in sein eigenes Kind »..\branches\test_branch« kopieren
(can not copy path ».« into its own child »..\branches\test_branch«)
While this actually does not come as a surprise to me, it makes me wonder if you did anything in-between that you forgot to mention? I checked the V 1.7 release notes, but couldn't find any indication that the cp command changed, so you should get the same error.
|
|
|
|
|
Are you doing this in the repo, or a working copy checked out from the root of the repo? Because that command works just fine for me...
Although I think the safest command to use is probably
svn cp ^/trunk svn/branches/some-name
because that operates solely on the repository - you then need to svn update your working copy to receive the newly created branch... The ^ character is shorthand for the repository root, so you don't need to type the whole URL.
But.... all of this is more complex than typing hg branch some-name, so that's why I'll take Mercurial 
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
I literally copied the commands you listed (except for the file paths). Also your question shouldn't be necessary: the two arguments were working copy locations*, a repository location must be an URL. I'm not familiar with the syntax you suggested her, using the caret, but if you want to create a branch in the repository, the syntax that worked for me is
svn cp file:///d:/svn-repos/test2/trunk file:///d:/svn-repos/test2/branches/test_branch
* P.S.: You can not directly access the repository directory structure from either the command line or Windows Explorer, nor can you tell SVN to interpret subsequent path arguments as such. That is why "." can only be a working copy location, not a repository location.
Stuart Dootson wrote: But.... all of this is more complex than typing hg branch some-name, so that's why I'll take Mercurial 
And I use [RMB]-Branch from the TSVN context menu. 
modified 26-Apr-13 3:44am.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
