On Thu, Nov 26, 2009 at 07:46:55AM +0100, Andreas Krey wrote:
> On Thu, 26 Nov 2009 00:01:08 +0000, Stefan Sperling wrote:
> 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',
Sorry, there is no server-side client configuration support yet.
> as well as a way to set eol-style to native
> on all new files that aren't binary. That would really be useful.
You could use auto-props.
> > > 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.
Switch the current working copy to the URL of a different
working copy? If you already have a working copy of the branch
around, why would you want to switch the other one?
> > > 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. :-)
export BLA=^/subsys/component/module/branches/bla
svn switch $BLA
> > 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.
That's what I meant to say, just expressed differently.
> > 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.
Then set up some variables you can use in your shell.
You could write a small tool that does this and share it with others.
> > 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.
Sorry, you'll have to live with this.
> > How exactly would knowing when something was added to mergeinfo solve
> > this problem?
>
> See the other mail. It's about reconstructing the ancestry graph.
I replied there.
> > 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'.
That's because those systems are different.
You know what? My vi can't do emacs shortcuts! Blasphemy!
(I know that emacs can do vi shortcuts and everything else under the sun,
but that comes at a price, too.)
> > Yes, git has a simpler model, they merge either everything or nothing.
>
> But still: git proves that free merges without --reintegrate are possible.
Yes, as I said, the kinds of merges git can track are enough
for many users. In hindsight, if the ability to track subtree merges
had been dropped from svn's mergetracking design, that would
have simplified a few things. But neither you nor I were around at
the time to suggest this.
> > 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.
Well, they can compare files line-by-line at runtime for free
because they have all versions of all files sitting on disk.
> > > 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".
The concept is now set in stone. It's been released and will have
to stay until Subversion 2.0.
> > 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.
See Mark's and my replies.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424576
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 12:34:56 CET