On Thu, 26 Nov 2009 00:01:08 +0000, Stefan Sperling wrote:
...
> You mean like an optional list switch destinations which provide svn
> with knowledge about "good" switches? And any other switch would
> produce a warning or an error?
This is not a feature request; I do merge or switch seldom enough
not to have this problem in earnest (although the only time I did
I needed to refetch 30MB of tree via GPRS or wait for better
connectivity).
...
> Something like that should be easy to implement as a client-side
> configuration option. Enforcing it from the server side would
> probably be impossible.
The problem is that I would like that to come automatically out
of the 'svn checkout', as well as a way to set eol-style to native
on all new files that aren't binary. That would really be useful.
> > I know. Progress is trickling in. I'd like (and expect)
> > 'svn switch ../branches/mybranch' to do the obvious instead
> > of giving me 'not a working copy there'.
>
> What do you think is obvious?
Well, switching to a working copy is pointless. So, take the
URL (of svn info) and apply the relativ path given to it,
and switch to that URL.
> Do you mean that svn should get the URL from the working copy
> path you passed to it, which lives in directory `pwd`/../branches/mybranch?
No, the other way around, $THISURL/../branches/mybranch, with removal of
.. and the preceding path element.
> > Hmm, perhaps ^../branches/bla as a shortcut relative to the
> > URL of the current directory (as of svn info)?
>
> I don't see what you want to achieve here.
> You're still typing "branches/bla"?
Yes, but I'm not typing ^/subsys/component/module/branches/bla
any more. 'svn switch -b bla' would require svn of actually
knowing about branches. :-)
> svn ls ^.
>
> means "list the content of the current directory's URL".
> And also ^.. meaning "URL of the parent directory".
No, it should mean the parent of the URL of this directory.
> But what problem do you really want to solve by adding more of such syntax?
Typing. Lots of it. Nowadays, when I do a switch, I do a svn info
go get something to copy the module's base URL from. That is a lot
more work than typing the relativ path.
> The current syntax is "^/" referring to the repository root.
And that's a good thing, especially in svn:externals.
...
> Any other expectations than not having to carry out a --record-only
> merge to get a reintegrated branch to soak up changes from trunk again?
YES. Never to see --reintegrate or --record-only, as with the other VCSes.
...
> How exactly would knowing when something was added to mergeinfo solve
> this problem?
See the other mail. It's about reconstructing the ancestry graph.
...
> If there wasn't a problem with automatic reflective merges they would
> already be implemented. Reflective merges are possible, just not
> automatically handled.
Sorry, but a lot of systems prove that this is wrong or 'only true for svn'.
...
> Yes, git has a simpler model, they merge either everything or nothing.
But still: git proves that free merges without --reintegrate are possible.
> They also support cherry picking but it's not tracked.
No, instead they have a way of checking outside the record whether
exactly that commit has already been applied to another branch.
I never used that, I use cherry picking primarily to correct it
when I accidentally put something on the wrong branch.
git is cherry-picking by commit rather than by file, anyway.
...
> > Information about merges is actually ancestry
> > information, as the ancestry graph of a file determines how and
> > what to merge. (git does that on a whole-tree basis.) And a file
>
> This is true for git but not for Subversion.
> I see how merging in theory affects ancestry, but it does not
> affect the concept of ancestry that Subversion uses.
It affects the concept it should use. I cannot quite imagine
svn saying "our merge support will never be as good as the other's".
...
> What other information would this copyfrom-like mergeinfo provide
> than what svn:mergeinfo provides today? Even copyfrom information
> is stored as a single path:revision pair.
I don't really know. I am sure that the --reintegrate dance is
unnecessary but I haven't quite figured out exactly what went
wrong with svn in that respect.
Andreas
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424502
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-26 07:48:03 CET