The thing about this is that git-svn (un?)fortunately works so well that you can get all of these benefits with the main repo still in SVN. Hence, it is really a moot point regarding a switch to git for the main repo. E.g.:> Actually that's true today with svn. We have a ton of changes here we'd > like to submit but the process is really painful.Is there any difference from the standpoint of how "painful" it would be to merge back between: 1. pure-git workflow: your development is on a branch that you then need to integrate upstream. 2. use the git mirror with git-svn: your development is on a branch that you then need to integrate back into mainline. Both seem to be basically the same. I agree that if you aren't developing with git for the local branch, then it would be insanely painful, but the fact that git-svn allows for git on the local side gives all of the benefits in this particular case without having to move the main repo away from SVN. -- Sean Silva On Thu, Nov 15, 2012 at 6:59 PM, <dag at cray.com> wrote:> David Chisnall <David.Chisnall at cl.cam.ac.uk> writes: > >> On 15 Nov 2012, at 12:31, <dag at cray.com> wrote: >> >>> - Easier third-party merging. Merging via git merge/rebase is MUCH >>> simpler than merging a tarball from svn. I know the llvm leaders >>> don't seem to care about this but it is a real issue for many users. >>> >>> - Ease of fork/merge. git makes it easy to experiment with long-lived >>> development branches. svn forces all development into trunk which >>> limits experimentation and innovation. >> >> Neither of these are true. There is nothing stopping people from >> working in branches in svn > > Yes there is. I have asked about it many times and have always been > refused. > >> and merging from branches is easy. > > That is absolutely not true for any significant merge operation. > >> The advantage with git is that it's very easy to have your fork >> somewhere where no one else sees it and your changes get lost and >> forgotten. > > Actually that's true today with svn. We have a ton of changes here we'd > like to submit but the process is really painful. > >> Your point about small incremental commits is also untrue. svn >> encourages small incremental commits and, more importantly, encourages >> small incremental pushes upstream. > > An svn commit is an expensive operation. A git commit is a cheap > operation. That's why I'm referring to. Development inertia under svn > tends to steer the developer toward making larger changes before > committing. With git committing becomes an almost unnoticed part of the > process. At least that's been my experience. > >> This is something we want to encourage: we don't want to make it >> easier for people to have private forks than it is to push them >> upstream. > > There is value in those private forks. As I said, having places to > experiment is important. > > -David > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi,
This probably isn't significant evidence about using svn as the
authoritative revision control system for llvm but more just to point out
that the svn users tend to consider that the only thing one would use
revision control for is the mainstream development history tracking.
I'll note that I during working ("development" but also bug-fixing
and
experimentation) since the advent of git I've been using revision storage
much, much more extensively than before. For instance, I've got a private
branch with a cron job takes a commit of the working tree every 10 minutes
(even if it isn't in a compilable state) cleaning them out after every day
and likewise one that takes a commit every hour. This means that if I
suddenly see a weird behaviour change in something I'm working on I can step
back through revisions until I find one which compiles and has the old
behaviour, then diff the two to find stuff to investiage rather than have to
think "what did I change recently". Likewise I'm into the habit of
creating
throwaway merge branches with mainline when doing development in order to
check if there's conflicts. And it provides a nice way to synchronise
"personal" development between machines which can't see a common
filesystem.
Currently I do all this using git (with the external feed from git-svn) and
then create "considered" patches against svn once I've figured
stuff out.
Now none of this has any effect on the "proper world-viewable
linearised-history source repository". What's nice about git (and I
suppose
hg, although I've not used that as intensively) is that both these internal
activities and the longer-term, externally visible pieces of development is
that they're done with the same tools and in the same personal repository
(with bits that don't get transmitted to external repos). On the other hand
SVN is deliberately designed to work well as "the central revision control
history" of the project but not to be the tool for doing anything else.
Which is fine, but it is a particular choice of what's within its remit
rather than any fundamental constraint.
Couple of additional comments inline.
On Thu, Nov 15, 2012 at 6:59 PM, <dag at cray.com>
wrote:> David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:
>
>> On 15 Nov 2012, at 12:31, <dag at cray.com> wrote:
>>
>>> - Easier third-party merging. Merging via git merge/rebase is MUCH
>>> simpler than merging a tarball from svn. I know the llvm leaders
>>> don't seem to care about this but it is a real issue for many
users.
>>>
>>> - Ease of fork/merge. git makes it easy to experiment with
long-lived
>>> development branches. svn forces all development into trunk which
>>> limits experimentation and innovation.
>>
>> Neither of these are true. There is nothing stopping people from
>> working in branches in svn
>
> Yes there is. I have asked about it many times and have always been
> refused.
Actually, the fact that (if you're using svn to store information about your
branch) this branch is getting stored on the central server can be
off-putting, particularly if you're storing a lot of stuff you plan to later
delete once you've figured out the right way to do things.
>> and merging from branches is easy.
>
> That is absolutely not true for any significant merge operation.
>
>> The advantage with git is that it's very easy to have your fork
>> somewhere where no one else sees it and your changes get lost and
>> forgotten.
>
> Actually that's true today with svn. We have a ton of changes here
we'd
> like to submit but the process is really painful.
>
>> Your point about small incremental commits is also untrue. svn
>> encourages small incremental commits and, more importantly, encourages
>> small incremental pushes upstream.
>
> An svn commit is an expensive operation. A git commit is a cheap
> operation. That's why I'm referring to. Development inertia under
svn
> tends to steer the developer toward making larger changes before
> committing. With git committing becomes an almost unnoticed part of the
> process. At least that's been my experience.
>
>> This is something we want to encourage: we don't want to make it
>> easier for people to have private forks than it is to push them
>> upstream.
>
> There is value in those private forks. As I said, having places to
> experiment is important.
Note that there's a tendency to call everything a "fork" even if
it's really
just "thinking/experimentation", but the word "fork" conveys
in the readers
mind something deliberate, thought-out and long-term.
Regards,
Dave
Sean Silva <silvas at purdue.edu> writes:> The thing about this is that git-svn (un?)fortunately works so well > that you can get all of these benefits with the main repo still in > SVN. Hence, it is really a moot point regarding a switch to git for > the main repo. E.g.:I agree that git-svn is a big help but it is not the same as native git. For one thing, it can't integrate with a private svn repository.> I agree that if you aren't developing with git for the local branch, > then it would be insanely painfulThat is exactly the situation I am in. I have tried to change this many times but it is out of my control, unfortunately. Yet I keep trying. :) I'm not saying that LLVM should switch to git because of my situation. I'm simply highlighting the way things are now and expressing that the LLVM community is missing out on a bunch of improvements we've made because it is so darn painful to merge.> but the fact that git-svn allows for git on the local side gives all > of the benefits in this particular case without having to move the > main repo away from SVN.That's not entirely true. When working with git-svn, one has to be *very* careful about managing local branches. Because git-svn requires frequent rebases, sharing local branches with other developers becomes tricky. Not impossible, but you have to be very careful not to screw things up. It doesn't _feel_ like git, totally. It mostly does, until you hit the corner cases. -David
David Tweed <david.tweed at arm.com> writes:>>> Neither of these are true. There is nothing stopping people from >>> working in branches in svn >> >> Yes there is. I have asked about it many times and have always been >> refused. > > Actually, the fact that (if you're using svn to store information about your > branch) this branch is getting stored on the central server can be > off-putting, particularly if you're storing a lot of stuff you plan to later > delete once you've figured out the right way to do things.That's *exactly* the problem of svn branches.>>> This is something we want to encourage: we don't want to make it >>> easier for people to have private forks than it is to push them >>> upstream. >> >> There is value in those private forks. As I said, having places to >> experiment is important. > > Note that there's a tendency to call everything a "fork" even if it's really > just "thinking/experimentation", but the word "fork" conveys in the readers > mind something deliberate, thought-out and long-term.That's right. The terminology is unfortunate. By "fork" I mean exactly the short-to-medium-lived private branch used for staging changes and experiments that you described well. -David
>> I agree that if you aren't developing with git for the local branch, >> then it would be insanely painful > > That is exactly the situation I am in. I have tried to change this many > times but it is out of my control, unfortunately. Yet I keep trying. > :)I'm glad you're persevering! You will eventually succeed :)> I'm not saying that LLVM should switch to git because of my situation. > I'm simply highlighting the way things are now and expressing that the > LLVM community is missing out on a bunch of improvements we've made > because it is so darn painful to merge.I think you might be jumping the gun on the conclusion here. Rather than pinpointing painful merging as the direct cause, I would more generally say that the problem is that you haven't found a way to effectively coordinate your internal development so that it results of your development can be contributed upstream in a timely manner. You might need to get creative.>> but the fact that git-svn allows for git on the local side gives all >> of the benefits in this particular case without having to move the >> main repo away from SVN. > > That's not entirely true. When working with git-svn, one has to be > *very* careful about managing local branches. Because git-svn requires > frequent rebases, sharing local branches with other developers becomes > tricky. Not impossible, but you have to be very careful not to screw > things up. It doesn't _feel_ like git, totally. It mostly does, until > you hit the corner cases.This is something I hadn't considered (the branch sharing), but it's a really good point. Since I'm not currently developing my changes in collaboration with other developers, I haven't experienced this. However, I can think of a good way to circumvent the problem; it comes from the following observation: git-svn is simply your gateway to physically creating the revisions in the central SVN repo and fetching new revisions, but otherwise need not condition your development. I think that the issue that you are running into is that you have misplaced the "gateway" to be too close to your everyday team development. If you want, feel free to PM me and we can discuss the particular forces at play in your situation and try to come up with a workflow that works :) -- Sean Silva On Fri, Nov 16, 2012 at 12:19 PM, <dag at cray.com> wrote:> Sean Silva <silvas at purdue.edu> writes: > >> The thing about this is that git-svn (un?)fortunately works so well >> that you can get all of these benefits with the main repo still in >> SVN. Hence, it is really a moot point regarding a switch to git for >> the main repo. E.g.: > > I agree that git-svn is a big help but it is not the same as native git. > For one thing, it can't integrate with a private svn repository. > >> I agree that if you aren't developing with git for the local branch, >> then it would be insanely painful > > That is exactly the situation I am in. I have tried to change this many > times but it is out of my control, unfortunately. Yet I keep trying. > :) > > I'm not saying that LLVM should switch to git because of my situation. > I'm simply highlighting the way things are now and expressing that the > LLVM community is missing out on a bunch of improvements we've made > because it is so darn painful to merge. > >> but the fact that git-svn allows for git on the local side gives all >> of the benefits in this particular case without having to move the >> main repo away from SVN. > > That's not entirely true. When working with git-svn, one has to be > *very* careful about managing local branches. Because git-svn requires > frequent rebases, sharing local branches with other developers becomes > tricky. Not impossible, but you have to be very careful not to screw > things up. It doesn't _feel_ like git, totally. It mostly does, until > you hit the corner cases. > > -David