I'll have to take a look at git-annex and bup.

You're right we've developed a tool that makes externals management easier 
(checking if a newer revision of a external exist, with the option to 
update to a desired new revision and show the log of the referenced 
But we won't get rid of externals as we're not only referencing libraries. 
We've built a settings-system that is based on text-files which relies upon 

If you get used to externals - they are not too bad. But still there is 
some manual work involved and you have be really careful when changing 
externals (if one wants to avoid breaking some other code that may or may 
not rely on your code....)

Am Mittwoch, 3. Juni 2015 14:38:50 UTC+2 schrieb Magnus Therning:
> On 3 June 2015 at 11:23, Thomas Ferris Nicolaisen <tfn...@gmail.com 
> <javascript:>> wrote: 
> > On Wednesday, June 3, 2015 at 9:31:40 AM UTC+2, reinhar...@yahoo.de 
> wrote: 
> >> 
> >> Hi! 
> >> 
> >> how can SVN Externals be mapped to GIT? 
> >> 
> >> We're heavily using externals. We reference folders and files with 
> >> externals at a certain revision. 
> > 
> > 
> > If your goal is to pick single files from shared projects, perhaps using 
> > something like https://git-annex.branchable.com/ could be an option. I 
> was 
> > hoping that git-annex supports SVN as a backend, but unfortunately it 
> does 
> > not (yet - you can write your own extensions though). 
> > 
> > If you're willing to place these assets that you have through 
> svn-externals 
> > on some other kind of server, you could use annex out of the box to sync 
> > single files into your repository. Just a half thought-through idea :) 
> I was trying to not get up on my soap box ;) 
> My experience with SVN externals is that they should be avoided at all 
> costs.  Use of them requires so much self-discipline (and usually a 
> lot of scripting) that it simply isn't worth it. 
> There are numerous ways to deal with assets, git-annex is an excellent 
> one for assets that change somewhat regularly, you can layer git-annex 
> on [bup][1] for even more excellence.  Otherwise just putting them on 
> a read-only network share (the only time you need to write is when you 
> add a new asset, you never remove) works very well for assets that are 
> updated rarely. 
> /M 
> [1]: https://github.com/bup/bup 
> -- 
> Magnus Therning                      OpenPGP: 0xAB4DFBA4 
> email: mag...@therning.org <javascript:>   jabber: mag...@therning.org 
> <javascript:> 
> twitter: magthe               http://therning.org/magnus 


You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to