Andrew Dunstan wrote:
Jeremy Drake wrote:
rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/
The buildfarm howto has somewhat more complete instructions (including
how to adjust the various cvs config files if you need to). I set it up
the other day - took me about
Warren Turkal wrote:
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
Warren Turkal wrote:
On Saturday 24 February 2007 16:47, Chad Wagner wrote:
head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
head ? ?1.3;
access;
symbols
? ? ? ? Release-1-6-0:1.1.1.1
On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
OK, I definately had added the semicolons, so I am confused why you
don't see them. Anyway, I have remove the duplicate 'creation:' lines,
so now there is only one line in each file. Let me know how that works.
Everything looks good
Warren Turkal wrote:
On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
OK, I definately had added the semicolons, so I am confused why you
don't see them. Anyway, I have remove the duplicate 'creation:' lines,
so now there is only one line in each file. Let me know how that works.
On Tuesday 27 February 2007 13:50, Andrew Dunstan wrote:
You know, you can prune what is rsynced.
I am not sure why you brought this up, but yes I did know this.
my rsync line looks like this:
rsync -avzCH --delete --exclude-from=/home/cvsmirror/pg-exclude
Warren Turkal wrote:
On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
OK, I definately had added the semicolons, so I am confused why you
don't see them. Anyway, I have remove the duplicate 'creation:' lines,
so now there is only one line in each file. Let me know how that works.
Warren Turkal wrote:
On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
OK, I definately had added the semicolons, so I am confused why you
don't see them. Anyway, I have remove the duplicate 'creation:' lines,
so now there is only one line in each file. Let me know how that works.
Warren Turkal wrote:
On Tuesday 27 February 2007 13:50, Andrew Dunstan wrote:
You know, you can prune what is rsynced.
I am not sure why you brought this up, but yes I did know this.
Well I thought it might be useful to prune that directory you were
having trouble with. But we
Warren == Warren Turkal [EMAIL PROTECTED] writes:
Warren Is it possible to obtain a mirror of the CVS repository?
I use CVSup to locally mirror the repo. They've had the repo
available via CVSup for some years now.
I use this .cvsup file:
,(/mirror/CvsUp/Postgresql/pgsql.cvsup)
|
Alvaro Herrera wrote:
Warren Turkal wrote:
On Saturday 24 February 2007 15:18, Alvaro Herrera wrote:
Keep in mind that the repository as converted by Josh, above, is
strangely corrupted in weird and unpredictable ways.
Would you care to elaborate on that statement? I'd like to check my
Hi,
Andrew Dunstan wrote:
O.k. everyone pay attention, I am about to agree with Greg! ;)
Greg are their tools to migrate CVS to monotone or whatever your
favorite is? The reason I ask is that I migrate the CVS to SVN every 4
hours I think it is and it isn't perfect.
monotone ships it's own
Hi,
Matthew D. Fuller wrote:
I would say that a far greater contributor in practice would simply be
frequency. If you diverge on your significant feature for 6 months,
then try to merge in upstream changes from the main dev, you will be
in hell no matter what merge algorithm you use.
Do you
Hi,
Tom Lane wrote:
Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts. AFAICS that has nothing to do with the SCMS in use
and everything to do with whether your diff command is
On Mon, Feb 26, 2007 at 11:07:01AM +0100, Markus Schiltknecht wrote:
Tom Lane wrote:
Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts. AFAICS that has nothing to do with the SCMS in
Hi,
[EMAIL PROTECTED] wrote:
I'll have to try kdiff3 - but the merge command, although it often works,
I strongly dislike when it marks up the lines as there was a conflict here
and gives you three files in the directory to choose to start from. This is
far too manual, which invites mistakes.
I imagine the problems are caused by manual mangling of the files in the
early days, like the perl5 dir stuff you found.
Hmm, if you only checked using the Trac interface, maybe this is an
issue with re-creating the SVN repo.
Joshua, do you run trac-admin /path/to/trac/env resync after
Warren Turkal wrote:
On Saturday 24 February 2007 16:47, Chad Wagner wrote:
head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
head ? ?1.3;
access;
symbols
? ? ? ? Release-1-6-0:1.1.1.1
? ? ? ? creation:1.1.1.1
? ? ? ? creation:1.1.1; ? ? What the heck happened here?
locks;
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
Done. Any other problems?
I don't see the fix in the rsync archive. When will it show up there? For
reference, the changes were needed in the following files in
cvsroot/pgsql/src/interfaces/perl5/Attic:
* ApachePg.pl,v
*
On Monday 26 February 2007 08:04, Markus Schiltknecht wrote:
Others you might want to try:
- meld (in python, IMO worse than kdiff3)
- xxdiff (I've never really used that one, but other monotone hackers
seem to like it as well)
A couple more options:
* kompare (this one is pretty)
*
Warren Turkal wrote:
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
Done. Any other problems?
I don't see the fix in the rsync archive. When will it show up there? For
About an hour.
reference, the changes were needed in the following files in
Joshua D. Drake wrote:
I imagine the problems are caused by manual mangling of the files in the
early days, like the perl5 dir stuff you found.
Hmm, if you only checked using the Trac interface, maybe this is an
issue with re-creating the SVN repo.
Joshua, do you run trac-admin
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
Done. Any other problems?
Only figuring out the encoding issues with cvs.
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Monday 26 February 2007 10:04, Markus Schiltknecht wrote:
Hi,
[EMAIL PROTECTED] wrote:
I'll have to try kdiff3 - but the merge command, although it often
works, I strongly dislike when it marks up the lines as there was a
conflict here and gives you three files in the directory to
Joshua D. Drake wrote:
Joshua D. Drake wrote:
I imagine the problems are caused by manual mangling of the files in the
early days, like the perl5 dir stuff you found.
Hmm, if you only checked using the Trac interface, maybe this is an
issue with re-creating the SVN repo.
Joshua, do
Robert Treat wrote:
FWIW ClearCase also offers a command line version of its merge tool, where it
shows three columns (a la diff --side-by-side) and allows you to pick which
column you want to merge in (repo, change1, or change2 for example). It's a
nice attempt at doing it on the command
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Joshua D. Drake wrote:
I imagine the problems are caused by manual mangling of the files in the
early days, like the perl5 dir stuff you found.
Hmm, if you only checked using the Trac interface, maybe this is an
issue with re-creating the SVN
On Monday 26 February 2007 14:57, Andrew Dunstan wrote:
Robert Treat wrote:
FWIW ClearCase also offers a command line version of its merge tool,
where it shows three columns (a la diff --side-by-side) and allows you to
pick which column you want to merge in (repo, change1, or change2 for
On Mon, Feb 26, 2007 at 02:57:03PM -0500, Andrew Dunstan wrote:
Robert Treat wrote:
FWIW ClearCase also offers a command line version of its merge tool, where
it shows three columns (a la diff --side-by-side) and allows you to pick
which column you want to merge in (repo, change1, or change2
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
Warren Turkal wrote:
On Saturday 24 February 2007 16:47, Chad Wagner wrote:
head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
head ? ?1.3;
access;
symbols
? ? ? ? Release-1-6-0:1.1.1.1
? ? ? ? creation:1.1.1.1
?
On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote:
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 07:57:53 +0100, Markus
Schiltknecht [EMAIL PROTECTED] said:
markus Uh, yah. But I was refering to the lots of opinions on what
markus
In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 07:57:53 +0100, Markus
Schiltknecht [EMAIL PROTECTED] said:
markus Uh, yah. But I was refering to the lots of opinions on what
markus replacement system to use. This has not much to do with the
markus want or need (for lack of a better
In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 10:42:13 -0300, Alvaro
Herrera [EMAIL PROTECTED] said:
alvherre Richard Levitte - VMS Whacker wrote:
alvherre In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 07:57:53 +0100,
Markus Schiltknecht [EMAIL PROTECTED] said:
alvherre
alvherre
On Fri, Feb 23, 2007 at 11:28:07AM -0300, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote:
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 07:57:53 +0100,
Markus Schiltknecht [EMAIL
On Fri, 2007-02-23 at 18:02 -0500, Tom Lane wrote:
Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts. AFAICS that has nothing to do with the SCMS in use
and everything to do with
On Thu, 2007-02-22 at 14:49 -0300, Alvaro Herrera wrote:
For example, currently if I have a patch and somebody reviews it and
opines that I have to change foo to bar; then I resubmit the patch. How
do they find out whether I actually changed foo to bar? Currently there
are two alternatives:
On Sun, Feb 25, 2007 at 06:06:57PM -0500 I heard the voice of
Neil Conway, and lo! it spake thus:
The ability to do history-sensitive merges actually results in a
significant reduction in the need for manual conflict resolution.
I would say that a far greater contributor in practice would
Jeremy Drake wrote:
rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/
The buildfarm howto has somewhat more complete instructions (including
how to adjust the various cvs config files if you need to). I set it up
the other day - took me about 10 minutes.
On Saturday 24 February 2007 00:55, Magnus Hagander wrote:
AFAIK, git still does not support windows properly[1], which I would say
is a killer... Unless you can of course to everything you need through
one of those frontend protocols, but if you can do everything that way
then why would you
On Saturday 24 February 2007 00:24, Warren Turkal wrote:
The interesting thing about Git is that is has two way sync support for a
SVN repository also. You could run a Git repository pushing changes in real
time to a SVN repository and present a CVS frontend also. I would like to
try
Warren Turkal wrote:
On Saturday 24 February 2007 00:24, Warren Turkal wrote:
The interesting thing about Git is that is has two way sync support for a
SVN repository also. You could run a Git repository pushing changes in real
time to a SVN repository and present a CVS frontend also. I would
Warren Turkal wrote:
On Saturday 24 February 2007 00:55, Magnus Hagander wrote:
AFAIK, git still does not support windows properly[1], which I would say
is a killer... Unless you can of course to everything you need through
one of those frontend protocols, but if you can do everything that
Joshua D. Drake wrote:
Warren Turkal wrote:
As a followup, the cvs2svn conversion says the following.
Error summary:
ERROR: Multiple definitions of the symbol 'creation' in
'../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v'
ERROR: Multiple definitions of the
On Saturday 24 February 2007 15:18, Alvaro Herrera wrote:
Keep in mind that the repository as converted by Josh, above, is
strangely corrupted in weird and unpredictable ways.
Would you care to elaborate on that statement? I'd like to check my converted
repositories for what you're referring
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Warren Turkal wrote:
As a followup, the cvs2svn conversion says the following.
Error summary:
ERROR: Multiple definitions of the symbol 'creation' in
'../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v'
ERROR: Multiple
Warren Turkal wrote:
On Saturday 24 February 2007 15:18, Alvaro Herrera wrote:
Keep in mind that the repository as converted by Josh, above, is
strangely corrupted in weird and unpredictable ways.
Would you care to elaborate on that statement? I'd like to check my
converted repositories
On 2/24/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
ERROR: Multiple definitions of the symbol 'creation' in
'../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v'
ERROR: Multiple definitions of the symbol 'creation' in
On 2/24/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't know :-( I've tried to use the Trac site looking for particular
changesets and found that for some of them, the list of files are out of
sync with reality, and sometimes the diff don't have anything to do with
what the commit message
On Saturday 24 February 2007 16:47, Chad Wagner wrote:
head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
head 1.3;
access;
symbols
Release-1-6-0:1.1.1.1
creation:1.1.1.1
creation:1.1.1; What the heck happened here?
locks; strict;
comment @# @;
Can a
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 07:57:53 +0100, Markus
Schiltknecht [EMAIL PROTECTED] said:
markus Uh, yah. But I was refering to the lots of opinions on what
markus replacement system to use. This has not much to do with the
markus
[EMAIL PROTECTED] wrote:
On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote:
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 07:57:53 +0100, Markus
Schiltknecht [EMAIL PROTECTED] said:
markus Uh, yah. But I was refering to the lots
Warren Turkal wrote:
On Thursday 22 February 2007 20:39, Alvaro Herrera wrote:
Git is also pretty cool, too. You can even present a CVS interface on a
git repository. That might address the build farm issue.
But it wasn't portable, last time I checked.
Git is in the FreeBSD ports.
Moreover work on things like bitmapped indexes that other people want to help
on is hampered by this need to be mailing around patches. If two or three
people submit changes (based possibly on different old versions of the patch)
the main developer has to merge them into his version of the
Joshua D. Drake wrote:
Moreover work on things like bitmapped indexes that other people want to help
on is hampered by this need to be mailing around patches. If two or three
people submit changes (based possibly on different old versions of the patch)
the main developer has to merge them into
On Fri, Feb 23, 2007 at 08:32:34AM -0800, Joshua D. Drake wrote:
I am happy to help with this any way I can, because I would love to see
CVS take a big diving leap off the backend of mysql into the truncated
data set of hell.
That quote made the whole argument coming up again worthwhile. :)
--
On Feb 22, 9:49 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
Andrew Dunstan wrote:
It's also fair to say that this is a subject about which we usually get
much more noise from partisans of other SCM systems than from the
relatively small number of people who actually have to maintain the
Gregory Stark wrote:
You're still merging patches and reviewing patches by hand, without any of the
tools to, for example, view incremental changes in the branch, view the logs
of the branch, merge the branch into the code automatically taking into
account the known common ancestor. Instead of
Bruce Momjian wrote:
Gregory Stark wrote:
You're still merging patches and reviewing patches by hand, without any of
the
tools to, for example, view incremental changes in the branch, view the logs
of the branch, merge the branch into the code automatically taking into
account the
Alvaro Herrera wrote:
Bruce Momjian wrote:
Gregory Stark wrote:
You're still merging patches and reviewing patches by hand, without any
of the
tools to, for example, view incremental changes in the branch, view the
logs
of the branch, merge the branch into the code
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Gregory Stark wrote:
You're still merging patches and reviewing patches by hand, without any
of the
tools to, for example, view incremental changes in the branch, view the
logs
of the branch, merge the
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Gregory Stark wrote:
You're still merging patches and reviewing patches by hand, without
any of the
tools to, for example, view incremental changes in the branch, view
the logs
Bruce Momjian wrote:
My typical cycle is to take the patch, apply it to my tree, then cvs
diff and look at the diff, adjust the source, and rerun until I like the
diff and apply. How do I do that with this setup?
The most similar to what you're doing would be to
merge the patch's branch
Bruce Momjian wrote:
My typical cycle is to take the patch, apply it to my tree, then cvs
diff and look at the diff, adjust the source, and rerun until I like the
diff and apply. How do I do that with this setup?
The same, except that you don't need to take the patch out of an email
and into
Alvaro Herrera wrote:
Bruce Momjian wrote:
My typical cycle is to take the patch, apply it to my tree, then cvs
diff and look at the diff, adjust the source, and rerun until I like the
diff and apply. How do I do that with this setup?
The same, except that you don't need to take the
Alvaro Herrera [EMAIL PROTECTED] writes:
Yes, it's nice. Consider this: Andrew develops some changes to PL/perl
in his branch. Neil doesn't like something in those changes, so he
commits a fix there. In the meantime, Tom has been busy with his own
stuff and committing to the main branch;
On Friday 23 February 2007 15:50, you wrote:
How to people get a branch? Do they have their own logins?
If monotone is something like Git, you just create it in your local working
copy and push is somewhere public when you are ready, or you can just
generate the changeset and submit that.
wt
* Bruce Momjian:
The fact that you're still thinking in patch application means you're
still stuck in the CVS worldview. To apply a patch in a distributed
SCM(*) really means to merge a branch into the main development branch.
Of course, you can still see the entire diff -c if you want.
On Friday 23 February 2007 00:55, Lukas Kahwe Smith wrote:
Anyone who followed the thread willing to list the mentioned
requirements as well as the pro's and con's of the differnent options in
the developer wiki [1]?
Does the dev wiki even have a link from the site? I can't find a link under
Alvaro Herrera wrote:
Yes, it's nice. Consider this: Andrew develops some changes to PL/perl
in his branch. Neil doesn't like something in those changes, so he
commits a fix there.
If I understand right, another advantage is that the SCM will keep
track of which of those changes came from
On Fri, Feb 23, 2007 at 04:24:29PM -0700, Warren Turkal wrote:
On Friday 23 February 2007 15:50, you wrote:
How to people get a branch? Do they have their own logins?
If monotone is something like Git, you just create it in your local working
copy and push is somewhere public when you are
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
Yes, it's nice. Consider this: Andrew develops some changes to PL/perl
in his branch. Neil doesn't like something in those changes, so he
commits a fix there. In the meantime, Tom has been busy with his own
stuff
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I note also that CVS does have the ability to merge changes across
branches, we just choose not to use it that way.
And the reason why, I assume, is because it's hard to grant access to CVS
without granting access to do anything
On Friday 23 February 2007 08:30, Alvaro Herrera wrote:
Sorry, I mean Windows. We're taken pains to ensure Postgres runs on
Windows, we're not going to abandon that platform now.
This is why I would propose the use of the CVS gateway on top of git. Also,
Wikipedia claims there is a MingW32
Warren Turkal wrote:
On Friday 23 February 2007 08:30, Alvaro Herrera wrote:
Sorry, I mean Windows. We're taken pains to ensure Postgres runs on
Windows, we're not going to abandon that platform now.
This is why I would propose the use of the CVS gateway on top of git. Also,
Wikipedia
On Friday 23 February 2007 17:30, Gregory Stark wrote:
The distributed systems sound neat and do sound like they match our style
of working. But they seem like a big leap for a project that's still using
a buggy unmaintained pile of spaghetti code for fear of change. Subversion
is the path of
On Friday 23 February 2007 12:03, Andrew Hammond wrote:
While annoying, this is something that really only a problem for the
CVS maintainer (and anyone who's stuck waiting for the maintainer to
shuffle stuff). I suggest that while it would be nice to solve this
problem, it's more of a bonus
On Sat, 24 Feb 2007, Warren Turkal wrote:
The interesting thing about Git is that is has two way sync support for a SVN
repository also. You could run a Git repository pushing changes in real time
to a SVN repository and present a CVS frontend also. I would like to try
converting the CVS
On Friday 23 February 2007 23:10, Alvaro Herrera wrote:
To be frank, I don't like Git's data model. Git has always seemed
much too complex to use to me. I have more than enough with a single
distributed SCM.
Have you ever tried cogito or any of the other apps for interacting with a git
On Saturday 24 February 2007 00:32, Jeremy Drake wrote:
Use cvsup, or if you don't want to go through the effort of getting that
set up, use rsync:
rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/
Thanks for this. Is this documented somewhere that I should have looked?
wt
--
On Wednesday 21 February 2007 21:23, Warren Turkal wrote:
Are there any plans to move to another SCMS in the future? I am curious, I
guess.
Is it possible to obtain a mirror of the CVS repository? The version of CVS on
the repository server is incompatible with cvsps (at least the version on
Warren Turkal wrote:
On Friday 23 February 2007 17:30, Gregory Stark wrote:
The distributed systems sound neat and do sound like they match our style
of working. But they seem like a big leap for a project that's still using
a buggy unmaintained pile of spaghetti code for fear of change.
On Sat, 24 Feb 2007, Warren Turkal wrote:
On Saturday 24 February 2007 00:32, Jeremy Drake wrote:
Use cvsup, or if you don't want to go through the effort of getting that
set up, use rsync:
rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/
Thanks for this. Is this
Warren Turkal [EMAIL PROTECTED] writes:
On Thursday 22 February 2007 00:42, you wrote:
I think you just made my point for me.
I wasn't trying to convince so much as get an opinion.
Well, sure, it's all opinion ;-). But the overall costs of changing
SCMS are pretty enormous IMHO. We're not
Tom Lane [EMAIL PROTECTED] writes:
Warren Turkal [EMAIL PROTECTED] writes:
On Thursday 22 February 2007 00:05, Tom Lane wrote:
Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of
Gregory Stark [EMAIL PROTECTED] writes:
If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems.
Erm ... but this
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and
Gregory Stark wrote:
[on a related note, is something wrong with my cvs rsync tree or is
configure in the CVS repository? It's causing my patches to bloat
considerably since I added one line to configure.in]
cat CVS/Entries
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
[on a related note, is something wrong with my cvs rsync tree or is
configure in the CVS repository? It's causing my patches to bloat
considerably since I added one line to configure.in]
cat CVS/Entries
$ cat CVS/Entries
On Thu, 22 Feb 2007, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems.
Hi,
Andrew Dunstan wrote:
1. The buildfarm is very heavily dependent on CVS, and any change to
anything else will be quite painful. There is no guarantee that all the
members even have SVN installed,
But you can guarantee they have CVS or even cvsup installed? That seems
dubious to me.
Markus Schiltknecht wrote:
Hi,
Andrew Dunstan wrote:
1. The buildfarm is very heavily dependent on CVS, and any change to
anything else will be quite painful. There is no guarantee that all
the members even have SVN installed,
But you can guarantee they have CVS or even cvsup installed?
Hi,
[ I've CCed the monotone-devel list, as I'm sure those people are
interested, too. ]
Stefan Kaltenbrunner wrote:
Beside that - are all of the currently supported Platforms officially
supported by the proposed SCMSes ?
I can only speak for monotone. We have (had) buildbots for x86
Markus Schiltknecht wrote:
Hi,
Andrew Dunstan wrote:
1. The buildfarm is very heavily dependent on CVS, and any change to
anything else will be quite painful. There is no guarantee that all
the members even have SVN installed,
But you can guarantee they have CVS or even cvsup installed?
Hi,
Andrew Dunstan wrote:
CVSup is not required, and is absent from most existing clients. I don't
use it any more since the Fedora project stopped supporting it.
..which is quite understandable, concerning the PITA compiling modula-3
gives you (or at least has given me, it still hurts).
Hello Richard,
you should probably have read the thread on the PostgreSQL -hackers
mailing list I've linked to... at least you didn't make Tom's point ;-)
Richard Levitte - VMS Whacker wrote:
1. Do you want to stay with CVS or do you want to move to something
else?
Most PostgreSQL
Markus Schiltknecht wrote:
Richard Levitte - VMS Whacker wrote:
1. Do you want to stay with CVS or do you want to move to something
else?
Most PostgreSQL developers currently want to stay with CVS. Only some
desperate souls including myself are fiddling with other VCSes.
I really
Andrew Dunstan wrote:
Markus Schiltknecht wrote:
Richard Levitte - VMS Whacker wrote:
1. Do you want to stay with CVS or do you want to move to something
else?
Most PostgreSQL developers currently want to stay with CVS. Only some
desperate souls including myself are fiddling with
On Thursday 22 February 2007 05:26, Andrew Dunstan wrote:
2. Many people (and some buildfarm members) operate against mirrors of
the main repo which are created with rsync or CVSup. I am not aware of
any way to do the equivalent with SVN - any info would be gratefully
received. Of course, SVN
Andrew Dunstan [EMAIL PROTECTED] writes:
2. Many people (and some buildfarm members) operate against mirrors of the
main
repo which are created with rsync or CVSup. I am not aware of any way to do
the
equivalent with SVN - any info would be gratefully received. Of course, SVN
is
better
Andrew Dunstan wrote:
It's also fair to say that this is a subject about which we usually get
much more noise from partisans of other SCM systems than from the
relatively small number of people who actually have to maintain the
postgresql code. (As Tom has pointed out, our biggest pain
1 - 100 of 123 matches
Mail list logo
