Hi Guido, On Tuesday 10 of June 2008, Guido Ostkamp wrote:
> > Indeed :-) I see at least 2 possibilities here. The quick one would be > > to use git-svn which gives you lots of the git pluses, the problem is > > that you still have to have the SVN in mind - you would not push to the > > git repo, but rather use the special git-svn's commands to commit to the > > svn. > > this possibility #1 is exactly what I had in mind. Also, as committing > would certainly only be possible for selected persons, all others would > have to create a patch (a job easily done in git) and submit that the > usual way via IssueZilla, email etc. > > You certainly know that branches are handled quite differently in SVN and > DVCS systems. I haven't really played live with git-svn until now so that > I am not aware if and how well SVN branches are handled, especially when > old branches cease to exist, new branches are created or existing ones are > renamed (which are only directories in SVN). In worst case it might be > that only one branch can be mirrored at time (meaning: in one repository). > > Have you already been looking at this? Unfortunately, I know git-svn just from the documentation :-( From what they write there, it is possible to track more branches there, so tracking several CWSes (branches) should not be a problem. What concerns me a bit is the size of the repository - without actual trying, I have no idea how efficient git-svn will be on the full OOo import. > If not, I could do a little testing while you continue working on your > final SVN conversion, if that's of interest for you. That would be great :-) - please let us know when you have some results. > Should these tests be successful, some access to the real stuff on your > servers could be required later. Cannot promise the access to the OOo servers, but to the git-related one, it will be possible - see below. > BTW: I am a bit confused who is responsible for system admininistration on > your side. According to your email addresses Jens Heiner is from Sun, you > (Jan) are from SuSE CZ and Michael is from Novell. SUSE is now part of Novell :-) > Who is then responsible > for the server where OOo is maintained and where will this server be > located? For the SVN tree, Heiner is the responsible person. My involvement here is that: 1) I'd like git to be the final solution as _the_ OOo SCM :-) 2) I worked together with Heiner on a paper for the Engineering Steering Committee comparing the SCMs 3) I offered Heiner help with the conversion to SVN (when SVN won for this year), but unfortunately I'm a bit short of time these days, so no real work came from me :-( Point 1) implies that I'd like to setup the git server even outside of the 'official' facilities if necessary - which for the testing reasons etc. will be most probably the easiest start; later, if accepted etc., it will be easier to have it as close the official repository as possible of course. > > Another possibility would be to do something like you suggested, a git > > tree that would track the SVN development, and with cooperation of the > > CWS tools would sync the changes back (syncing back could be triggered > > by push immediately I guess, not sure about the tracking the development > > in SVN). I like this a bit more, but for sure it will be more work - > > help will be appreciated if you are interested. > > Honestly, I do not believe this approach would work. When something is > pushed to a Git repo, anything can have happened in the meantime in the > SVN master repo so that when attempting a merge you will probably get > critical conflicts when the two version have diverged. This will then > require manual intervention to resolve the conflict and cannot be done > automatically in a script triggered by a push. Yes, this is a bit tricky, but I believe solvable ;-) In combination with 'svn lock', the 'pre-receive' and 'update' hooks would fail in case there are changes in the SVN CWS branch that are not yet merged in the git branch. You are right that this would be quite a limitation if the changes from SVN would not be mirrored too often; OTOH thanks to the OOo development cycle where just the release engineers can commit to trunk and others manage just the CWSes (branches), this would not be that much a problem for the CWSes created and managed exclusively in the git tree. Regards, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
