{"thread":{"id":"14431","subject":"git-svn and svn properties on upstream","startedAt":"2008-07-12T19:58:09Z","lastAt":"2008-07-13T00:07:36Z","messageCount":3,"participants":["Paul Talacko","Avery Pennarun","Peter Harris"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"83101","messageId":"608871.39190.qm@web27807.mail.ukl.yahoo.com","threadId":"14431","inReplyTo":null,"subject":"git-svn and svn properties on upstream","fromName":"Paul Talacko","fromEmail":"gnuruandstuff@yahoo.co.uk","sentAt":"2008-07-12T19:58:09Z","receivedAt":"2008-07-12T19:58:09Z","isPatch":false,"sender":{"key":"gnuruandstuff@yahoo.co.uk","avatar":null},"body":"Hello,\n\nI know other people have asked how they can set svn properties on files that they are dcommit-ing to an upstream svn repository.\n\nI 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.\n\nI 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. \n\nSince then I've been thinking about what could be a general solution. One thing I can think of is this:\n\n* amend SVN::Git::Editor::generate_diffs to add another hash key to amend properties.\n* look for ~/.subversion/config or /etc/subversion/config to see whether auto-props are set\n* if set, set the properties accordingly in the @mods array of hashes.\n* SVN::Git::Editor::A then sets the properties according to the contents of the $mods hash ref, using set_file_prop().\n\nThat 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!\n\nAnother 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.\n\nThe 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.\n\nWhat do people think?  Which of the above ideas would be most appropriate/useful?\n\nThanks\n\nPaul\n\n\n      __________________________________________________________\nNot happy with your email address?.\nGet the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html\n"},{"id":"83104","messageId":"32541b130807121430ia85a3c8u3efc0b5a8591eb44@mail.gmail.com","threadId":"14431","inReplyTo":"608871.39190.qm@web27807.mail.ukl.yahoo.com","subject":"Re: git-svn and svn properties on upstream","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-12T21:30:58Z","receivedAt":"2008-07-12T21:30:58Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/12/08, Paul Talacko <gnuruandstuff@yahoo.co.uk> wrote:\n>  * amend SVN::Git::Editor::generate_diffs to add another hash key to amend properties.\n>  * look for ~/.subversion/config or /etc/subversion/config to see whether auto-props are set\n>  * if set, set the properties accordingly in the @mods array of hashes.\n>  * SVN::Git::Editor::A then sets the properties according to the contents of the $mods hash\n> ref, using set_file_prop().\n\nThis sounds like it would be fine for almost all users.  Specifically\nme :)  I think it's a good starting point, so you could build\nsomething even more flexible on top later if you wanted.\n\nI guess in an ideal world there'd be a way to track svn properties in\nthe git history, but I have no idea where such things should probably\ngo.\n\nHave fun,\n\nAvery\n"},{"id":"83113","messageId":"eaa105840807121707s45dfe936m94a0ceeac82d8a66@mail.gmail.com","threadId":"14431","inReplyTo":"32541b130807121430ia85a3c8u3efc0b5a8591eb44@mail.gmail.com","subject":"Re: git-svn and svn properties on upstream","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2008-07-13T00:07:36Z","receivedAt":"2008-07-13T00:07:36Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Sat, Jul 12, 2008 at 5:30 PM, Avery Pennarun wrote:\n>\n> I guess in an ideal world there'd be a way to track svn properties in\n> the git history, but I have no idea where such things should probably\n> go.\n\n.gitattributes?\n\nsvn:eol-style translates roughly into crlf. svn:keywords translates\n(partially) into ident.\n\ngit appears to ignore unrecognized entries in .gitattributes. The rest\ncan be stored there untranslated (or lightly translated - ':' is not\nlegal for .gitattributes names, if I read the comments correctly).\n\nPeter Harris\n"}]}