On Fri, 19 Apr 2019 22:10:12 +, Sad Clouds wrote:
...
> > - not really doing branches properly or usefully
> What is your definition of a "useful" branch?
A branch that the VCS actually knows as a separate concept,
not this branches-are-paths 'potentially interesting idea',
that turned out to
On Thu, 18 Apr 2019 19:38:06 -0700
"Greg A. Woods" wrote:
> The whole range of other more direct problems with SVN is of course
> the real issue with it:
>
> - not really doing branches properly or usefully
What is your definition of a "useful" branch?
> - not doing or tracking merges properly
On Fri, Apr 19, 2019 at 2:07 AM 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 th
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 being second
> with their push?
This all
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 at you specifically. I'm just trying to
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 blame? Subversion? W
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 f
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 at
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 b
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 being
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 res
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 b
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 breakin
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 chang
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 b
> 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 developer
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
> pul
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 n
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 o
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 wo
At Wed, 17 Apr 2019 21:31:36 +0200, Johnny Billquist wrote:
Subject: Re: Alternative DVCS to git: hg?
>
> On 2019-04-17 16:49, Hisashi T Fujinaka wrote:
> >
> > After using git for my day job, I find that I depend on a lot of features
> > that are missing in cvs.
>
On April 17, 2019 10:49:49 AM EDT, Hisashi T Fujinaka
wrote:
>On Wed, 17 Apr 2019, Johnny Billquist wrote:
>
>> Agreed. And after having to deal with git for a couple of years, I
>must say
>> that I find git to be the most problematic VCS I have ever used.
>
>After using git for my day job, I
On 2019-04-17 23:59, Sad Clouds wrote:
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 issu
On 2019-04-17 17:58, Andrew Cagney wrote:
On Wed, 17 Apr 2019 at 06:33, Johnny Billquist wrote:
On 2019-04-17 10:02, Andreas Krey wrote:
On Wed, 17 Apr 2019 09:10:28 +, Johnny Billquist wrote:
...
Are you saying that subversion would interleave two commits? Commits in
subversion are supp
On 2019-04-17 23:09, Sad Clouds wrote:
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
On 2019-04-17 22:29, Hisashi T Fujinaka wrote:
On Wed, 17 Apr 2019, Johnny Billquist wrote:
On 2019-04-17 16:49, Hisashi T Fujinaka wrote:
On Wed, 17 Apr 2019, Johnny Billquist wrote:
Agreed. And after having to deal with git for a couple of years, I
must say that I find git to be the most p
On 2019-04-17 16:49, Hisashi T Fujinaka wrote:
On Wed, 17 Apr 2019, Johnny Billquist wrote:
Agreed. And after having to deal with git for a couple of years, I
must say that I find git to be the most problematic VCS I have ever used.
After using git for my day job, I find that I depend on a lo
On 2019-04-17 16:04, Andreas Krey wrote:
On Wed, 17 Apr 2019 14:17:19 +, Sad Clouds wrote:
On the other hand, if you expect "svn commit" to send the entire
snapshot of your local copy to the repository, this is totally absurd.
No, I expect it to atomically *check* whether the tree is up to
On 2019-04-17 14:58, Sad Clouds wrote:
On Wed, Apr 17, 2019 at 12:56 PM Johnny Billquist wrote:
Correct. However, with a branch, I can see, by looking at the file, in
the one place it is, what different branches that file exists in.
And what is the benefit of knowing all of the branches wher
On Wed, 17 Apr 2019, Johnny Billquist wrote:
On 2019-04-17 16:49, Hisashi T Fujinaka wrote:
On Wed, 17 Apr 2019, Johnny Billquist wrote:
Agreed. And after having to deal with git for a couple of years, I must
say that I find git to be the most problematic VCS I have ever used.
After using g
On 2019-04-17 14:42, Andreas Krey wrote:
On Wed, 17 Apr 2019 12:33:15 +, Johnny Billquist wrote:
I'm not following again. If I make a commit, I would assume it shows up
afterwards if I check the log for the file. Are you saying it won't?
Operative words being 'for the file'. Meaning yes, s
On Wed, 17 Apr 2019 at 06:33, Johnny Billquist wrote:
>
> On 2019-04-17 10:02, Andreas Krey wrote:
> > On Wed, 17 Apr 2019 09:10:28 +, Johnny Billquist wrote:
> > ...
> >> Are you saying that subversion would interleave two commits? Commits in
> >> subversion are supposed to be atomic. And eac
On Tue, Apr 16, 2019 at 09:57:02PM +0530, Mayuresh wrote:
> On Tue, Apr 16, 2019 at 11:12:10AM -0500, J. Lewis Muir wrote:
> > > I am just intrigued by it being written in python (except may be for the
> > > merge algorithm which is in C). Wouldn't most engineers prefer C/C++ for
> > > such a low l
On Wed, 17 Apr 2019, Johnny Billquist wrote:
Agreed. And after having to deal with git for a couple of years, I must say
that I find git to be the most problematic VCS I have ever used.
After using git for my day job, I find that I depend on a lot of features
that are missing in cvs.
All of t
On Wed, Apr 17, 2019 at 3:04 PM Andreas Krey wrote:
> No, I expect it to atomically *check* whether the tree is up to date.
> Simply so I can actually control what the next revision is going to be -
> that it is not going to break tests etc. (I have to say that I did not
> even know this particula
On Wed, 17 Apr 2019 14:17:19 +, Sad Clouds wrote:
...
> This is exactly how Subversion works.
You don't need to explain to me how it works. The problem is
not that it does not behave as advertised but that it works
in a way that is simply very short-sighted, and does not
allow to do things oth
On Wed, Apr 17, 2019 at 1:42 PM Andreas Krey wrote:
> I essentially want a way of indication 'Please commit this change,
> taking the revision I now have in my workspace as a basis of that
> commit' because a commit someone else is making in the meantime would
> break my commit - not on a VCS but
On Wed, Apr 17, 2019 at 12:56 PM Johnny Billquist wrote:
> Correct. However, with a branch, I can see, by looking at the file, in
> the one place it is, what different branches that file exists in.
>
And what is the benefit of knowing all of the branches where a
particular file exists? Branches a
On Wed, 17 Apr 2019 12:33:15 +, Johnny Billquist wrote:
...
> As long as I'm making changes that don't conflict with other changes,
> the VCS is fine. What you seem to be asking for is that the VCS should
> have a semantic understanding of a commit, and notice if the
> code/content make sens
On Wed, Apr 17, 2019 at 11:39 AM Johnny Billquist wrote:
> > What exactly is a "true branch"? Subversion does have branches, they
> > are fast and work quite well.
>
> Not really. Subversion have copies. There are differences. One being
> that it's very hard to even find out what "branches" exist
On 2019-04-17 13:47, Sad Clouds wrote:
On Wed, Apr 17, 2019 at 11:39 AM Johnny Billquist wrote:
What exactly is a "true branch"? Subversion does have branches, they
are fast and work quite well.
Not really. Subversion have copies. There are differences. One being
that it's very hard to even
On Wed, Apr 17, 2019 at 11:27 AM Benny Siegert wrote:
>
> Please do not turn this thread into a discussion about the merits of
> various VCSes for use in NetBSD. These discussions should take place
> on the tech-repository list. Thank you.
I think your rebuke is a bit misplaced here. There is not
On 2019-04-17 12:07, Sad Clouds wrote:
On Wed, Apr 17, 2019 at 1:38 AM Andrew Cagney wrote:
On Tue, 16 Apr 2019 at 15:05, Sad Clouds wrote:
Does it actually need to be distributed? If no, then what's wrong with
Subversion? Personally, I can't stand Git.
Subversion fails on two counts:
-
On 2019-04-17 10:02, Andreas Krey wrote:
On Wed, 17 Apr 2019 09:10:28 +, Johnny Billquist wrote:
...
Are you saying that subversion would interleave two commits? Commits in
subversion are supposed to be atomic. And each commit gets a
monotonically increasing commit number. Which also gives y
Please do not turn this thread into a discussion about the merits of
various VCSes for use in NetBSD. These discussions should take place
on the tech-repository list. Thank you.
On Wed, Apr 17, 2019 at 12:26 PM Sad Clouds wrote:
>
> On Tue, Apr 16, 2019 at 8:26 PM Greg Troxel wrote:
> >
> > Sad
On Tue, Apr 16, 2019 at 8:26 PM Greg Troxel wrote:
>
> Sad Clouds writes:
>
> > Does it actually need to be distributed? If no, then what's wrong with
> > Subversion? Personally, I can't stand Git.
>
> I think any open-source project needs a distributed VCS, so that people
> without commit bits c
On Wed, Apr 17, 2019 at 1:38 AM Andrew Cagney wrote:
>
> On Tue, 16 Apr 2019 at 15:05, Sad Clouds wrote:
> >
> > Does it actually need to be distributed? If no, then what's wrong with
> > Subversion? Personally, I can't stand Git.
>
> Subversion fails on two counts:
>
> - it isn't ACID (I'm told
On Wed, 17 Apr 2019 09:10:28 +, Johnny Billquist wrote:
...
> Are you saying that subversion would interleave two commits? Commits in
> subversion are supposed to be atomic. And each commit gets a
> monotonically increasing commit number. Which also gives you in which
> order the commits hap
On 2019-04-17 02:37, Andrew Cagney wrote:
On Tue, 16 Apr 2019 at 15:05, Sad Clouds wrote:
Does it actually need to be distributed? If no, then what's wrong with
Subversion? Personally, I can't stand Git.
Subversion fails on two counts:
- it isn't ACID (I'm told that's the correct DB term)
I
On Tue, 16 Apr 2019 at 15:05, Sad Clouds wrote:
>
> Does it actually need to be distributed? If no, then what's wrong with
> Subversion? Personally, I can't stand Git.
Subversion fails on two counts:
- it isn't ACID (I'm told that's the correct DB term)
In subversion parallel pushes are magicall
Sad Clouds writes:
> Does it actually need to be distributed? If no, then what's wrong with
> Subversion? Personally, I can't stand Git.
I think any open-source project needs a distributed VCS, so that people
without commit bits can fully prepare changes. With CVS, and it would
be the same, peo
Does it actually need to be distributed? If no, then what's wrong with
Subversion? Personally, I can't stand Git.
On Tue, Apr 16, 2019 at 12:57:33PM -0400, Greg Troxel wrote:
> It would be even cooler if rust built on every system NetBSD ran on with
> moderate amounts of CPU time! On my last rebuild on a 2006-vintage i386
> laptop (Core Duo, 4G RAM), it took 7h45m to build. But at least it
> built.
I think
=>
=> Came across this: plan to use rust for hg:
=> https://www.mercurial-scm.org/wiki/OxidationPlan
=>
=> Quite interesting. Would be good to see A. hg using a compiled language B.
=> rust getting another big user.
=>
=> Mayuresh
Rust can be quite a pig when compiling, and it would be nice to
Mayuresh writes:
> Came across this: plan to use rust for hg:
> https://www.mercurial-scm.org/wiki/OxidationPlan
>
> Quite interesting. Would be good to see A. hg using a compiled language B.
> rust getting another big user.
It would be even cooler if rust built on every system NetBSD ran on wit
On Tue, Apr 16, 2019 at 11:12:10AM -0500, J. Lewis Muir wrote:
> > I am just intrigued by it being written in python (except may be for the
> > merge algorithm which is in C). Wouldn't most engineers prefer C/C++ for
> > such a low level and key component?
>
> I'm sure some would. But others beli
On 04/16, Mayuresh wrote:
> On Mon, Apr 15, 2019 at 01:52:26PM -0500, J. Lewis Muir wrote:
> > Yes, it's a good alternative. I use it for most of my projects. It's
> > also used by a number of large projects such as Firefox, nginx, and
> > OpenJDK, and I gather it's on a short list of VCSes being
On Mon, Apr 15, 2019 at 01:52:26PM -0500, J. Lewis Muir wrote:
> Yes, it's a good alternative. I use it for most of my projects. It's
> also used by a number of large projects such as Firefox, nginx, and
> OpenJDK, and I gather it's on a short list of VCSes being evaluated by
> NetBSD as its next
On 04/15, Mayuresh wrote:
> I have tried out hg and it worked without any problems on an encfs mount.
>
> But I have used hg very little. Is that a good alternative to git or are
> there better options?
Yes, it's a good alternative. I use it for most of my projects. It's
also used by a number
65 matches
Mail list logo
