[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re: Future support to real tags and real branches?

From: Andreas Krey <a.krey_at_gmx.de>
Date: Thu, 26 Nov 2009 07:46:55 +0100

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.