Re: [boost] [1.36.0] Release schedule set

From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-05-24 11:32:36

2008/5/24 Jens Seidel <jensseidel_at_[hidden]>:
>
> 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)