# git-svn and svn properties on upstream 3 messages from 2008-07-12 to 2008-07-13. Participants: Paul Talacko, Avery Pennarun, Peter Harris. Thread: https://gitlist.dev/t/14431 ## Paul Talacko, 2008-07-12 19:58 Subject: git-svn and svn properties on upstream Message-ID: <608871.39190.qm@web27807.mail.ukl.yahoo.com> URL: https://gitlist.dev/e/608871.39190.qm%40web27807.mail.ukl.yahoo.com ``` Hello, I know other people have asked how they can set svn properties on files that they are dcommit-ing to an upstream svn repository. I had just this problem yesterday on a project that is hosted on sourceforge. I had added some files, but sourceforge refused the commit because I hadn't added the svn:mime-type and svn:eol-style properties. I spent some time going through the git-svn source code and I hacked a fix in &SVN::Git::Editor::A. It's pretty simple and sorted my problem out quickly. However, it's a general solution. Since then I've been thinking about what could be a general solution. One thing I can think of is this: * amend SVN::Git::Editor::generate_diffs to add another hash key to amend properties. * look for ~/.subversion/config or /etc/subversion/config to see whether auto-props are set * if set, set the properties accordingly in the @mods array of hashes. * SVN::Git::Editor::A then sets the properties according to the contents of the $mods hash ref, using set_file_prop(). That seems reasonably simple, however, I can already think of some use cases that miss. Notably, if autoprops are unsuitable for the project and properties have to be set for each individual file. A command line option would seem appropriate, but then we could get very long command lines! Another way would be to have another git svn command, propset for example, that a user could use at any time. The disadvantage is that this meta-data would have to be stored somewhere; it would be a db of file/path or object keys and svn property values. The A() and M() subroutines would access it when dcommit-ing. I guess it could be stored under .git/ somewhere. The projects I'm working on have a svn upstream, so I'd be willing to have a look at some of the options and write some code. What do people think? Which of the above ideas would be most appropriate/useful? Thanks Paul __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html ``` ## Avery Pennarun, 2008-07-12 21:30 Subject: Re: git-svn and svn properties on upstream Message-ID: <32541b130807121430ia85a3c8u3efc0b5a8591eb44@mail.gmail.com> URL: https://gitlist.dev/e/32541b130807121430ia85a3c8u3efc0b5a8591eb44%40mail.gmail.com In-Reply-To: <608871.39190.qm@web27807.mail.ukl.yahoo.com> ``` On 7/12/08, Paul Talacko wrote: > * amend SVN::Git::Editor::generate_diffs to add another hash key to amend properties. > * look for ~/.subversion/config or /etc/subversion/config to see whether auto-props are set > * if set, set the properties accordingly in the @mods array of hashes. > * SVN::Git::Editor::A then sets the properties according to the contents of the $mods hash > ref, using set_file_prop(). This sounds like it would be fine for almost all users. Specifically me :) I think it's a good starting point, so you could build something even more flexible on top later if you wanted. I guess in an ideal world there'd be a way to track svn properties in the git history, but I have no idea where such things should probably go. Have fun, Avery ``` ## Peter Harris, 2008-07-13 00:07 Subject: Re: git-svn and svn properties on upstream Message-ID: URL: https://gitlist.dev/e/eaa105840807121707s45dfe936m94a0ceeac82d8a66%40mail.gmail.com In-Reply-To: <32541b130807121430ia85a3c8u3efc0b5a8591eb44@mail.gmail.com> ``` On Sat, Jul 12, 2008 at 5:30 PM, Avery Pennarun wrote: > > I guess in an ideal world there'd be a way to track svn properties in > the git history, but I have no idea where such things should probably > go. .gitattributes? svn:eol-style translates roughly into crlf. svn:keywords translates (partially) into ident. git appears to ignore unrecognized entries in .gitattributes. The rest can be stored there untranslated (or lightly translated - ':' is not legal for .gitattributes names, if I read the comments correctly). Peter Harris ```