Daniel Shahaf <danielsh@xxxxxxxx>: > > Subversion's metadata doesn't have separate author and committer > > properties, and doesn't store anything but a Unix user ID as > > attribution. I don't see any way around this. > > You're not fully informed, then. > > 1) svn:author revprops can contain any UTF-8 string. They are not > restricted to Unix user id's. (For example, they can contain full > names, if the administrator so chooses.) Right. At one point during the development of this feature I was accidentally storing the full email field in this property. So I already knew that this is allowed at some level. And, I have no trouble believing that svn log will cheerfully echo anything that I choose to stuff in that field. But... (1) How much work would it be it to set up a Subversion installation so that when I svn commit, the tool does the right thing, e.g. puts a DVCS-style fullname/email string in there? (2) Have the tools been tested for bugs arising from having whitespace in that data? Really, if it's actually easy to set up DVCS-style globally unique IDs you Subversion guys ought to be shouting it from the housetops. The absence of this capability is a serious PITA in several situations, including for example migrating projects between forges. RFC: If I wrote a patch that let Subversion users set their own content string for the author field in ~/.subversion/config, would you merge it? Because I'd totally write that. > 2) You can define custom revision properties. In your case, the easiest > way would be to set an reposurgeon:author property, alongside the > svn:author property. Yeah, sure, I've assumed all along this wouldn't break if I tried it. If I actually thought you guys were capable of designing a data model with a perfectly general-looking store of key/value pairs and then arbitrarily restricting the key set so I couldn't do that, I'd almost have to find each and every one of you and kick your asses into next Tuesday on account of blatant stupidity. I have no such plans :-). But...what good does this capability do? OK, it would assist round-tripping back to gitspace, but while that's kind of cool I don't see any help for a normal Subversion workflow here. > 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 shouldn't Subversion join the DVCSes in the happy land of Internet-scoped attributions? > How does reposurgeon handle empty directories with (node) properties? Currently by ignoring all of them except svn:ignore, which it turns into .gitignore content on the gitspace side. And now vice-versa, too. Not clear what else it *could* do. I'd take suggestions. > > 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. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html