Working with git-svn or hgsubversion

[Rainer Müller]

On 2014-03-16 23:57, Clemens Lang wrote:
>> I propose we change to our policies to make it possible to work
>> with any tool locally, giving developers the choice to work with
>> the tool they like the most, be it svn, git-svn, hgsubversion,
>> bzr-svn, ...
> 
> While I like the idea of that, I'm not sure it's really going to work
> well in the long run. We already have a number of people committing
> changes from mercurial or git-svn and especially the keywords keep
> getting mixed up on those.

That's why I started this thread to find out and discuss what we have to
change to make it work.

>> a) No support for svn:ignore property Easy to accomplish, we would
>> just keep the equivalent in .gitignore and .hgignore files in the
>> repository root. The svn:ignore property would still be the
>> authoritative value. As these are barely set at all in the ports
>> tree, that should not be a problem.
> 
> I'd like to make a point against doing that. Keeping ignores in
> multiple files will only cause them to get out-of-sync. Some of the
> ignores in svn:ignore will sooner or later be committed as .gitignore
> files (to the SVN repository!), by oversight or on purpose. That's
> going to become a mess I'd like to avoid.

Of course I meant to store the .gitignore and .hgignore files in the
Subversion repository. In fact, we already have a .gitignore file in
trunk/. As I said, svn:ignore would still be authoritative and the other
files should only be generated.

.gitignore can be generated using 'git svn show-ignore > .gitignore'. As
an alternative, it would also be possible to use many small files in
each directory instead using 'git svn create-ignore'.

For .hgignore, Sean provided the command 'hg svn genignore' in another
reply.

The main starting point of this discussion was the ports tree, where
svn:ignore does not change often, so I don't see the additional
generation step as a problem.

Rainer