At Thu, 18 Apr 2019 09:23:31 +0100, Sad Clouds
wrote:
Subject: Re: Alternative DVCS to git: hg?
>
> On Thu, Apr 18, 2019 at 6:17 AM Greg A. Woods wrote:
> > SVN is a big steaming pile, though with "git svn" it can be held at
> > arm's length (though not quite far enough that the stench doesn't
On 2019-04-18 23:54, Sad Clouds wrote:
On Thu, 18 Apr 2019 23:37:28 +0200
Johnny Billquist wrote:
Don't shoot the messenger. I'm merely clarifying what Andrew was
getting at. And as I mentioned elsewhere, you hit the same thing in
git as well. It's a basic problem everywhere.
Not directed
On 2019-04-18 23:34, Sad Clouds wrote:
On Thu, 18 Apr 2019 22:40:45 +0200
Johnny Billquist wrote:
On 2019-04-18 22:04, Sad Clouds wrote:
On Thu, 18 Apr 2019 12:29:32 -0400
Andrew Cagney wrote:
When two fully tested commits hit the repo at the same time, and
the result is broken, who do I
On 2019-04-18 22:18, Andrew Cagney wrote:
On Thu, 18 Apr 2019 at 15:52, Johnny Billquist wrote:
Why do you insist on the "at the same time"? It can be at any time, and
the problem is the same.
there are various tricks to reduce the window; but yes
Thanks. :-)
With ACID, since the second
On 2019-04-18 22:04, Sad Clouds wrote:
On Thu, 18 Apr 2019 12:29:32 -0400
Andrew Cagney wrote:
When two fully tested commits hit the repo at the same time, and the
result is broken, who do I blame? Subversion? We can hardly wave a
finger at the developer who had the simple misfortune of
On Thu, 18 Apr 2019 at 16:04, Sad Clouds wrote:
>
> On Thu, 18 Apr 2019 12:29:32 -0400
> Andrew Cagney wrote:
>
> > When two fully tested commits hit the repo at the same time, and the
> > result is broken, who do I blame? Subversion? We can hardly wave a
> > finger at the developer who had the
On Thu, 18 Apr 2019 at 15:52, Johnny Billquist wrote:
> Why do you insist on the "at the same time"? It can be at any time, and
> the problem is the same.
there are various tricks to reduce the window; but yes
> > With ACID, since the second developer's change gets rejected, they can
> > be
On 2019-04-18 18:29, Andrew Cagney wrote:
On Thu, 18 Apr 2019 at 11:26, Martin Husemann wrote:
On Thu, Apr 18, 2019 at 11:18:06AM -0400, Andrew Cagney wrote:
So again, which commit broke the branch? With subversion, I can't
answer that question.
I am not sure I understand. svn log on the
On 2019-04-18 17:41, Andreas Krey wrote:
On Wed, 17 Apr 2019 21:31:36 +, Johnny Billquist wrote:
...
And since I'm a curious person as well, it would be interesting to hear
what you use and find so useful in git that you don't have in cvs.
Well, practically everything. Not even mentioning
On 2019-04-18 17:18, Andrew Cagney wrote:
The "work around" is to somehow "encourage" all the developers to go
through something like:
- test
- push
- pull
oh, "expletive",
- hack
- push
- pull
oh, "EXPLETIVE"
sure, like that will work ...
More normal would be:
hack
pull
push
Just to
On 2019-04-18 15:52, Andreas Krey wrote:
On Wed, 17 Apr 2019 21:29:39 +, Johnny Billquist wrote:
...
Uh... If you want to make sure the tree is up to date, you should do a
svn update, not svn commit.
An update doesn't help. It reduces the window in which someone
else could commit a
On Thu, 18 Apr 2019 at 11:26, Martin Husemann wrote:
>
> On Thu, Apr 18, 2019 at 11:18:06AM -0400, Andrew Cagney wrote:
> > So again, which commit broke the branch? With subversion, I can't
> > answer that question.
>
> I am not sure I understand. svn log on the branch certainly
> shows all
On Wed, 17 Apr 2019 21:31:36 +, Johnny Billquist wrote:
...
> And since I'm a curious person as well, it would be interesting to hear
> what you use and find so useful in git that you don't have in cvs.
Well, practically everything. Not even mentioning the 'distributed' part.
The fact that
> Subversion fails on two counts:
Subversion fails on 3 counts (for those keeping track, its so long I
forgot one):
> - it isn't ACID (I'm told that's the correct DB term)
> In subversion parallel pushes are magically merged, maybe. For
> instance: developer #1's deletes a .h macro and
On Thu, Apr 18, 2019 at 11:18:06AM -0400, Andrew Cagney wrote:
> So again, which commit broke the branch? With subversion, I can't
> answer that question.
I am not sure I understand. svn log on the branch certainly
shows all change sets, and all files touched. The point you are trying to
make is
> > The "work around" is to somehow "encourage" all the developers to go
> > through something like:
> >
> > - test
> > - push
> > - pull
> > oh, "expletive",
> > - hack
> > - push
> > - pull
> > oh, "EXPLETIVE"
> >
> >
> > sure, like that will work ...
>
> More normal would be:
>
> hack
>
On Wed, 17 Apr 2019 21:29:39 +, Johnny Billquist wrote:
...
> Uh... If you want to make sure the tree is up to date, you should do a
> svn update, not svn commit.
An update doesn't help. It reduces the window in which someone
else could commit a breaking change, but it doesn't close it.
I'd
On Thu, Apr 18, 2019 at 6:17 AM Greg A. Woods wrote:
> SVN is a big steaming pile, though with "git svn" it can be held at
> arm's length (though not quite far enough that the stench doesn't still
> wear on one).
Could you quantify the above statement? You seem to be saying
Subversion is a pile
On Wed, 17 Apr 2019 23:28:41 +0200
Johnny Billquist wrote:
> > Well, you don't need to specify full URL, there are well known
> > shortcuts:
>
> Sorry, I'm still not impressed. Why on earth they didn't do "proper"
> branches and tags is beyond me, and my biggest issues with
> subversion. Apart
On Wed, 17 Apr 2019 21:23:43 +0200
Johnny Billquist wrote:
> Right. We don't want sane tags or branches, so instead we need to
> specify full URLs when we want a different version.
>
> I'm not saying subversion can't be used. Just that some things annoy
> me, and in my view are rather bad. I
20 matches
Mail list logo
