git-svn and svn properties on upstream

git-svn and svn properties on upstream

[Paul Talacko]

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

Re: git-svn and svn properties on upstream

[Avery Pennarun]

On 7/12/08, Paul Talacko <gnuruandstuff@yahoo.co.uk> 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

Re: git-svn and svn properties on upstream

[Peter Harris]

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