Yawar Amin <yawar.a...@gmail.com> writes:
> Hi Derek,
>
> On 2011-01-03, at 11:53, Derek Atkins wrote:
>
>>> […]
>>
>> Apparently there are also issues with importing branches and tags
>> appropriately, as per John's other email.
>
> There is an issue in that git-svn imports branches and tags as remote
> refs (roughly, pointers to the head of a branch). But I’m fairly sure
> I can work around that. I’m running an import right now, following the
> instructions in [1]. I’ll write up a description when I’m sure it
> works.
Okay, so it's a peculiarity of git-svn, not a problem with svn itself.
>>> […]
>>
>> Do we really have a synchronization problem? What exactly do you mean
>> by that?
>
> This is something only git-svn users experience. Cloning a large
> remote SVN repository in Git is a long operation. Committing back to
> SVN is also a little tricky in certain situations. A gatekeeper would
> move all that to one point, giving Git users a Git repo that ‘just
> works’. It would collect all Git users’ work. Then someone comfortable
> with the way git-svn works could commit all the collected work into
> the SVN trunk or other branches.
Similarly, this is also a peculiarity of git-svn and not a problem with
svn itself.
>>> […]
>> […]
>> After we get some experience with git and
>> after we'd figured out the proper incantations to completely migrate
>> from svn, then we should *not* work from the gatekeeper repo but instead
>> we should start with a fresh "Master" repo off SVN and make that the
>> "official" repo.
>
> Sure, that’s not a problem. You’ll probably want to do it though, on
> the machine that physically stores the SVN repo, because it is a long
> and bandwidth-intensive operation.
Sure. If we do decide to move over to git then I'm happy to do the
final conversion locally. That's why I was asking that good notes be
taken so the process could be repeated.
>>> […]
>>
>> Is remembering the 'branchy development' really a requirement here? SVN
>> certainly supports feature and bugfix branches, and we've certainly used
>> it that way. It does have a problem that you cannot really merge
>> multiple times, so you have to worry about multiple merges from a branch
>> back to trunk.
>
> Multiple merges (or rebases for people doing private work) would
> certainly be very convenient in certain situations.
Of course, but I thought svn-1.6 handles this better?
>>> […]
>>
>> Here's where I have to question: does this experimentation have to
>> happen in a way that is easily publically published? In what way does
>> the status quo not allow this?
>
> That’s a good point. I guess it comes down to how comfortable you are
> with creating and maintaining (i.e. periodically merging in the latest
> changes from trunk) multiple branches in SVN versus in Git. I find Git
> easier, especially the maintaining part.
Sure. Here's where I have to admit that I've never actually used git.
(Actually, that's not completely true -- I've ran git a couple time to
checkout some code, but the command was copied from the web and run only
once). Git has been on my list of things I need to look at once I have
the time, but like most everyone it's hard to find that time.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
