2008/5/24 Jens Seidel <jensseidel@users.sf.net>:
Is this true for Subversion 1.5 as well? This weekend will a release candidate be published, the release is planned one week later. This new merge command is interactive and seems to work well.
I've no idea, I've not been following the 1.5 release schedule, but I think that distributed tools that have the entire history in the working copy are still going to have far better merging capabilities because it simply doesn't need round trips to the server; Subversion is painfully slow once you've seen how quickly git et al. can do merges.
I don't know git (but try to use it) and merging in other distributed version control systems (such as darcs, mercurial).
better merge tools that enable this kind of integration to be done easily; again I refer people to the example of the linux kernel or git for how this kind of thing is done.
Maybe this could be renamed into branches/next_release.
Try to avoid moving branches as I suggested earlier it makes it harder to migrate to other version control systems in the future and also
I can verify this for git-svn or however it is called (git functionaliy over svn). I just assumed the migration tool is buggy and that one just has to file a bug report (not yet done) ...
I guess it can be detected and worked around via the import scripts BUT I think that it is really subversions structure (or lack of) that is the problem and makes it impossible to automatically detect every possible case that could have occurred in the history. (svn:externals are also a big problem in importing too but thankfully boost doesn't make use of them)
plays havoc with working copies if a new branch with the previous name is then created again as subversion doesn't detect the move. This is
I think this has changed recently (ehm, I mean in 1.5): * 'svn update' now sometimes copies or moves local files, for efficiency
Does it work in this case?: svn co http://foo/branch/release (some one else moves branch release to be release_last then creates a new branch release) svn up It certainly didn't last I tried it with 1.4. (It's also unclear what the expected behaviour should be: should svn up now retrieve release_last or release?)
part of the reason I consider subversion's branching model of using paths for branches to be broken.
James, you should not consider software such as Subversion as static. If you don't like a aspect and others agree with you just report it and wait for the fix (or even better provide a patch).
I don't consider it as static, but this isn't the only gripe I have against subversion. I've worked with subversion extensively and have now moved all my personal code projects to use git as I find it far more usable (the only downside I currently see in distributed systems is the inability to restrict access to parts of the repository; one case where I've used subversion is a commercial repository that is shared between companies. Due to licensing and security issues some of the code is only visible to certain developers, I guess the solution is to use a separate repository for the restricted code but that also has its downsides). Besides I don't think that subversion would move away from using paths for branches since its at the very core of how it has been designed (the model seems attractive at first but in reality it becomes a pain as it allows users to do very silly things to the repository)