(note, other half of the thread is on dev_at_svn only..)
Eric S. Raymond wrote on Thu, Nov 29, 2012 at 06:46:37 -0500:
> Daniel Shahaf <danielsh_at_elego.de>:
> > You might also seek community consensus to reserve an svn:foo name for
> > the "original author" property --- perhaps svn:original-author --- so
> > that reposurgeon and other git->svn tools can interoperate in the way
> > they transfer the "original author" information.
>
> OK. But I like the idea of letting the users set their own author
> content string better. Instead of another layer of kluges, why
I don't see the kludge here --- git has a "author" != "committer"
distinction, svn doesn't, so if you want to grow that distinction the
most natural way is a new property. Storing additional information in
svn:author is a separate issue.
> > > Subversion has a concept of "flows"; that is, named segments of
> > > history corresponding to files or directories that are created when
> > > the path is added, cloned when the path is copied, and deleted when
> > > the path is deleted. This information is not preserved in import
> > > streams or the internal representation that reposurgeon uses. Thus,
> > > after editing, the flow boundaries of a Subversion history may be
> > > arbitrarily changed.
> > >
> > > This is me being obsessive about documenting the details. I think it
> > > is doubtful that most Subversion users even know flows exist.
> >
> > I think you're saying that adds might turn into copies, and vice-versa.
> > That is something users would notice --- it is certainly exposed in the
> > UI --- even though node-id's are not exposed to clients.
>
> I'm saying nobody thinks of flows when they do branch copies. It's
> not just that users don't see node IDs, it's that no part of most users'
> mental model of how Subversion works resembles them.
I'm still not sure what you have in mind. I note that 'svn log' and
'svn blame' cross both file copies and branch creation --- that's one
effect of "'svn cp foo bar; svn ci' causes bar to be related to foo".
> --
> Eric S. Raymond
Received on 2012-11-29 14:43:24 CET