On Fri, Mar 23, 2007 at 06:13:16PM +0000, Julian Phillips wrote:
quoted text
> On Fri, 23 Mar 2007, Bruno Cesar Ribas wrote:
> 
> >On Fri, Mar 23, 2007 at 11:34:26AM +0100, Karl Hasselström wrote:
> >>On 2007-03-23 01:36:11 +0000, Julian Phillips wrote:
> >>
> >>>In particular it's how the client finds out about things like
> >>>symlinks and line ending conversion. It may be necessary to provide
> >>>some basic support for some of the properties in the svn:...
> >>>namespace in order for the Subversion repo access library not to
> >>>refuse to talk to the git server.
> >>
> >>Maybe the pragmatic solution would be to have built-in handling of a
> >>few properties such as svn:executable and svn:ignore that have git
> >>equivalents, and just emulate all other properties with files.
> >
> >My idea is to write the git-svnserver!!! I think it will be easier.
> 
> Almost certainly - I don't think anyone was proposing otherwise?  The repo 
> access library I was referring to is one of the libraries used by the 
> client - specifically the one used to talk to a remote server (I think 
> it may be called ra or something?  I'm not familiar with Subversion 
> internals).
> 
> >
> >To begin coding, i plan to write basic functions [updade,commit,checkout,
> >copy,merge,...] then start to implement most "complex" instructions.
> 
> Ok, but ...
> 
> I don't think that merge is a basic function in Subversion.  I believe 
> that it is all client side using diffs provided by the server into the 
> working copy, certainly it is up to the user to commit the result. 
> Unfortunately that would make it necesary to do some very nasty work 
> server side to try and autodetect merges - git-svnimport (and git-svn?) 
> already does this sort of thing.  There are noises about this changing at 
> some point though ...
> 
> >
> >As spearce said before, the idea of this is to migrate from svn to git
> >without many trouble in transition, so basic can work as the initial 
> >thought.
> 
> Which means that you have to at the very least support the basic 
> operations of the Subversion supplied svn client.  And my point was that I 
> wouldn't be surprised if this meant dealing with properties, since 
> subversion uses properties to expose things like the log message, commit 
> date and author for revisions and other misc. info for files.  You may not 
> even be able to get commit/checkout working without _some_ property 
> support.
> 
> Having said that, I don't think it would be a _bad_ thing if this work 
> went far enough that one could replace a Subversion server without any 
> users even noticing ;)

I began to think about it... the idea to have a git-svnserver is to move from
svn to git and get my dev team not to worry about the transition at the
start, but it is a good idea to make people get moving to git idea of
devlopment, right?
Or the main idea is that we will have a group devloping under git repo and a
group under svn-gateway for the same project? I don't see a point to have
this! when a repo type is defined everyone must begin to understand that way,
even if it was changed in the middle of the project.

When decided above, we can define our dev of this project. Because as people
make those 'strange' stuff at svn repo that git won't support we will have to
make some workarounds to get git understand those things, and if we have some
people migrated do git and some using svn they will not see some 'svn tags'
on git repo.

That's why i think it should be a transition thing from svn to git.



quoted text
> 
> -- 
> Julian
> 
>  ---
> You know you're using the computer too much when:
> a party sucks if theres no computers to use.
> 	-- 
> 	electrofreak


-- 
Bruno Ribas - ribas@c3sl.ufpr.br
http://web.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html