2009/6/7 Tom Lane :
> So there are a lot of good reasons to work backwards in patching.
> I don't believe that these would be outweighed by some advantage
> in the mechanics of applying an unchanging patch to multiple
> branches (especially since AFAICT the mechanical advantage would
> be pretty da
Hi,
Quoting "Nicolas Barbier" :
ISTM that back-patching
I take this to mean "back-patching by cherry picking".
a change to a file that wasn't modified on the
back-branch leads exactly to merging a change to a (file-wise)
ancestor?
Regarding the file's contents - and therefore the immediate
Markus Wanner wrote:
Quoting "Mark Mielke" :
I am a theory person - I run things in my head. To me, the concept of
having more context to make the right decision, and an algorithm that
takes advantage of this context to make the right decision, is simple
and compelling on its own. Knowing the
Hi,
Quoting "Nicolas Barbier" :
If I understand correctly, "nearby variable renaming" refers to
changes to the few lines surrounding the changes-to-be-merged.
Hm.. I took that to mean "changes on the same line". I now realize
this interpretation has been an overly strict interpretation.
T
Robert Haas wrote:
> On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane wrote:
>> ... but I'm not at all excited about cluttering the
>> long-term project history with a zillion micro-commits. One of the
>> things I find most annoying about reviewing the current commit history
>> is that Bruce has taken a
Hi,
Quoting "Mark Mielke" :
I am a theory person - I run things in my head. To me, the concept
of having more context to make the right decision, and an algorithm
that takes advantage of this context to make the right decision, is
simple and compelling on its own. Knowing the algorithms tha
2009/6/7 Markus Wanner :
> However, there's no special whitespace treatment. Nor anything remotely
> as clever as "nearby variable renaming". There's no such magic, the
> developer still needs to tell the tool what he wants.
If I understand correctly, "nearby variable renaming" refers to
changes
Tom Lane wrote:
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common ancest
Hi,
Greg Stark wrote:
> For what it's worth that's certainly not true. Any user maintaining a
> patched version of the source tree for production use will want to
> merge in any patches for older releases. For example anyone using the
> CONNECT BY patch with 8.3 will surely want to take any 8.3 pa
Hi,
Tom Lane wrote:
> How robust is git about dealing with whitespace changes,
> nearby variable renamings, and such?
Monotone tracks changes line by line. I'm not sure about git. Kdiff3,
which is used to do the manual merge, if necessary, uses some finer
grained method, AFAIK.
However, there's
Hi,
Andrew Dunstan wrote:
> One fact to keep in mind is that, unlike most other FOSS projects, we
> keep quite a large number of branches live.
So far I thought exactly that would be a good reason for migrating to
something like git. Those claim to ease working on multiple branches in
parallel, a
Hi,
Tom Lane wrote:
> There are a number of possible reasons, but here are a few that hold for me:
Thank you for this very good collection. I'm still wondering about
what's the best way to represent this in git (or others). Cherry-picking
is arguably the simplest variant. Maybe that can be combin
Tom Lane wrote:
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common ance
On Fri, Jun 5, 2009 at 4:37 PM, Tom Lane wrote:
>
> However, given that we don't do any real development on the back
> branches, it might be that trying to be smart about this is a waste of
> time anyway. Surely only the HEAD version of the patch is going to be
> something that other developers ca
Mark Mielke writes:
> Tom Lane wrote:
>> I have heard it claimed that git is more intelligent than plain
>> diff/patch and could successfully merge patches in cases that currently
>> require manual adjustment of the sort Andrew describes.
>> ...
>> However, I have yet to see any actual *evidence*
Tom Lane wrote:
I have heard it claimed that git is more intelligent than plain
diff/patch and could successfully merge patches in cases that currently
require manual adjustment of the sort Andrew describes. If that's
really true to any significant extent, then it could represent a benefit
large
Andrew Dunstan writes:
> [ most of a good summary omitted ]
> ... Even fairly trivial patches can suffer
> from this: the pretty small plperl fixes I applied yesterday and the day
> before, required adjustment going from one branch to the previous one in
> about three out of five back branch ca
Markus Wanner wrote:
Hi,
Andrew Dunstan wrote:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable.
The monotone page about daggy fixes does quite a good job in explaining
why it is helpful. I think it's how to make bes
Markus Wanner writes:
> Out of interest, and not necessarily related to Postgres: why do you
> think it's unreasonable? Fixing the problem where it was introduced
> sounds like the most reasonable place to fix it, IMO.
There are a number of possible reasons, but here are a few that hold for me:
Hi,
Andrew Dunstan wrote:
> Yeah, a requirement to work from the back branch forward is quite
> unacceptable IMNSHO. It's also quite unreasonable.
The monotone page about daggy fixes does quite a good job in explaining
why it is helpful. I think it's how to make best use of these tools. And
it's
Hi,
Tom Lane wrote:
> I think it's already been made crystal clear that the people who
> actually do this work don't do it that way, and are uninterested in
> allowing their tools to force them to do it that way.
That's well understood.
> Patching from
> HEAD back works better for us for a numbe
* Andrew Dunstan [090605 14:41]:
> The whole point is that we want something better *that suits our work
> patterns*. Almost all the backpatching that gets done is by the
> committers. So we have a bunch of concerns that are not relevant to that
> vast majority of developers. In particular,
Aidan Van Dyk wrote:
* Andrew Dunstan [090605 13:55]:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
help, not to force an unnatural work pattern on us.
Again, just to make it clear, git i
* Andrew Dunstan [090605 13:55]:
> Yeah, a requirement to work from the back branch forward is quite
> unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
> help, not to force an unnatural work pattern on us.
Again, just to make it clear, git isn't going to *force* anyone
Tom Lane wrote:
> Robert Haas writes:
> > [ about micro commits ]
> > (As a side benefit, if one of my little micro-commits turns out to
> > have a bug, you can easily revert *just that commit*, without having
> > to manually sort out exactly which pieces related to that change.)
>
> I don't actu
On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ about micro commits ]
>> (As a side benefit, if one of my little micro-commits turns out to
>> have a bug, you can easily revert *just that commit*, without having
>> to manually sort out exactly which pieces related to th
Robert Haas writes:
> [ about micro commits ]
> (As a side benefit, if one of my little micro-commits turns out to
> have a bug, you can easily revert *just that commit*, without having
> to manually sort out exactly which pieces related to that change.)
I don't actually have a lot of faith in su
On Fri, Jun 5, 2009 at 11:37 AM, Tom Lane wrote:
> However, given that we don't do any real development on the back
> branches, it might be that trying to be smart about this is a waste of
> time anyway. Surely only the HEAD version of the patch is going to be
> something that other developers car
Robert Haas writes:
> I'm sure someone is going to come in here and again recommend merging,
> but I'm going to again recommend not merging. Cherry-picking is the
> way to go here. Or just commit to each branch completely separately
> with the same commit message; cherry-pick at least IMO is jus
On Fri, Jun 5, 2009 at 9:38 AM, Tom Lane wrote:
> "Markus Wanner" writes:
>> Note that a requirement for daggy fixes is that "the bug is fixed
>> close to the point where it was introduced". So fixing it on the
>> oldest stable branch that introduced a bug instead of fixing it on
>> HEAD and then
Tom Lane wrote:
"Markus Wanner" writes:
Note that a requirement for daggy fixes is that "the bug is fixed
close to the point where it was introduced". So fixing it on the
oldest stable branch that introduced a bug instead of fixing it on
HEAD and then back-porting would certainly be a
"Markus Wanner" writes:
> Note that a requirement for daggy fixes is that "the bug is fixed
> close to the point where it was introduced". So fixing it on the
> oldest stable branch that introduced a bug instead of fixing it on
> HEAD and then back-porting would certainly be a step into the
Hi,
Quoting "Ron Mayer" :
Seems you'd want to do is create a new branch as close to the point
where the bug was introduced - and then merge that forward into each
of the branches.
Thank you for pointing this out. As a fan of monotone I certainly know
and like that way. However, for people wh
Markus Wanner wrote:
> The "new branches getting merged up" could work. That is, applying the
> fix to the oldest back-branch which requires the fix first and then
> merge it to all newer ones, including HEAD. However, that would require
> some rethinking: instead of creating bugfix-patches for HEA
Hi,
Quoting "Marko Kreen" :
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
something but I don't see any reason one is better than the other.
As pointed out by others, it doesn't make sense to merge (all
Hi,
Quoting "Tom Lane" :
BTW, Markus: you do realize "thomas" is not me but Tom Lockhart?
Uh.. thanks, that name has fallen through the cracks, before. I've
added it now, it will be included in the next sample conversion.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pg
Hi,
Quoting "Greg Stark" :
Hmm. I see. I'm not sure we've ever added files to back branches
either. I'm less sure of that though.
We did from time to time. Every merge commit in my current conversion
contains at least one such file that got added as part of a back
patch. The perl file men
On 4 Jun 2009, at 09:11, "Markus Wanner" wrote:
Hi,
Quoting "Greg Stark" :
This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of
renaming files. But my example is about renaming with git *after*
the conversion. Git *does* sup
Hi,
Quoting "Greg Stark" :
This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of renaming
files. But my example is about renaming with git *after* the
conversion. Git *does* support renaming (to some extent). However, it
fails
Robert Haas wrote:
> But I
> wonder if it would make more sense to include some kind of metadata in
> the commit message (or some other property of the commit? does git
> support that?) to make it not depend on that.
>From elsewhere in this thread[1], 'The "git cherry-pick" ... "-x" flag adds
a n
* Marko Kreen [090603 11:28]:
> I'm not certain, but I remember using cherry pick and seeing
> several commits in result. This seems to be a point that needs
> to be checked.
I'm not sure what you're recalling, but git cherry-pick takes a single
commit, and applies it as a single commit (or, w
On 6/3/09, Aidan Van Dyk wrote:
> * Marko Kreen [090603 11:12]:
> > Well, thats good to know, but this also seems to mean it's rather bad
> > tool for back-patching, as you risk including random unwanted commits
> > too that happened in the HEAD meantime. But also, it's very good
> > tool fo
* Marko Kreen [090603 11:12]:
> Well, thats good to know, but this also seems to mean it's rather bad
> tool for back-patching, as you risk including random unwanted commits
> too that happened in the HEAD meantime. But also, it's very good
> tool for forward-patching.
It doesn't "pull in comm
On 6/3/09, Aidan Van Dyk wrote:
> * Marko Kreen [090603 10:26]:
> > Thats true, but it's not representable in VCS, unless you use cherry-pick,
> > which is just UI around patch transport. But considering separate
> > local trees (with can optionally contain local per-fix branches),
> > it is
On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen wrote:
> Various scenarios with git cherry-pick and similar tools would still
> result in duplicate commits, so we would need a git log post-processor
> anyway if we want to somehow group them together for eg. weekly commit
> summary. And such post-pro
Robert Haas wrote:
> On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander wrote:
>>> I'm not sure whether we should mark the old branches getting merges
>>> down or the new branches getting merged up. I suspect I'm missing
>>> something but I don't see any reason one is better than the other.
>> If yo
* Marko Kreen [090603 10:26]:
> Thats true, but it's not representable in VCS, unless you use cherry-pick,
> which is just UI around patch transport. But considering separate
> local trees (with can optionally contain local per-fix branches),
> it is possible to separate the fix-developement fr
* Magnus Hagander [090603 10:13]:
>
> Right, if it adds additional metadata that lets the tools do their magic
> better, and it's still easy to filter out, I don't see a downside.
Note, that it could (and likely will) have a downside when you get to
doing real merge-based development... A "merge
On 6/3/09, Magnus Hagander wrote:
> Robert Haas wrote:
> > On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander
> wrote:
>
> >>> I'm not sure whether we should mark the old branches getting merges
> >>> down or the new branches getting merged up. I suspect I'm missing
> >>> something but I don't
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander wrote:
> Greg Stark wrote:
>> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote:
>>> "git log --no-merges" hides the actual merge commits if that is what you
>>> want.
>>
>> Ooh! Life seems so much sweeter now!
>>
>> Given that we don't have to s
On 6/3/09, Greg Stark wrote:
> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote:
> > "git log --no-merges" hides the actual merge commits if that is what you
> > want.
>
>
> Ooh! Life seems so much sweeter now!
>
> Given that we don't have to see them then I'm all for marking bug fix
> pat
Greg Stark wrote:
> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote:
>> "git log --no-merges" hides the actual merge commits if that is what you
>> want.
>
> Ooh! Life seems so much sweeter now!
>
> Given that we don't have to see them then I'm all for marking bug fix
> patches which were ap
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote:
> "git log --no-merges" hides the actual merge commits if that is what you
> want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm all for marking bug fix
patches which were applied to multiple branches as me
Hi,
On 06/03/2009 02:08 PM, Greg Stark wrote:
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner wrote:
That would make the git history match Tom's "same commit message"
implicit CVS history that cvs2pcl was giving him. I find git-log's
output including merge commits kind of strange and annoying my
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner wrote:
> If you create separate commits during the conversion, rename that file on
> the master branch
This is all completely irrelevant to the CVS import. I don't think
we've ever renamed files because CVS can't handle it cleanly.
It does sound to
Hi,
Quoting "Marko Kreen" :
The example was not actual case from Postgres CVS history,
but hypotetical situation without checking if it already works
with GIT.
Of course it is a simplified example, but it resembles what could
happen i.e. to the file doc/src/sgml/generate_history.pl, which go
Aidan Van Dyk wrote:
> * Markus Wanner [090602 10:23]:
>> As mentioned before, I'd personally favor *all* of the back-ports to
>> actually be merges of some sort, because that's what they effectively
>> are. However, that also bring up the question of how we are going to do
>> back-patches in
On 6/2/09, Markus Wanner wrote:
> Quoting "Marko Kreen" :
> > And what silly side effects are you talking about?
> >
>
> I'm talking about spurious file duplicates popping up after a rename and a
> merge, see my example in this thread.
The example was not actual case from Postgres CVS history,
Hi,
Quoting "Marko Kreen" :
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
I already am there. And I don't want to go back, thanks. But my bias
for monotone certainly shines through, y
Hi,
Quoting "Tom Lane" :
FWIW, the tool that I customarily use (cvs2cl) considers commits on
different branches to be "the same" if they have the same commit message
and occur sufficiently close together (within a few minutes). My
committing habits have been designed around that behavior for ye
On Tue, Jun 2, 2009 at 11:08 AM, Tom Lane wrote:
> Aidan Van Dyk writes:
>> * Markus Wanner [090602 10:23]:
>>> You consider it a mess, I consider it a better and more valid
>>> representation of the mess that CVS is.
>
>> So much better that it makes the history as useless as CVS... I think
>>
On 6/2/09, Markus Wanner wrote:
> [academic nitpicking]
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
> > So please turn the merge logic off. If this cannot be turned off,
> > cvs2git is
On 6/2/09, Tom Lane wrote:
> Aidan Van Dyk writes:
> > * Markus Wanner [090602 10:23]:
>
> >> You consider it a mess, I consider it a better and more valid
> >> representation of the mess that CVS is.
>
> > So much better that it makes the history as useless as CVS... I think
> > one of the
On Tue, Jun 2, 2009 at 4:02 PM, Alvaro Herrera
wrote:
>
>
> The Monotone folk call this "daggy fixes" and it seems a clean way to
> handle things.
>
> http://www.monotone.ca/wiki/DaggyFixes/
Is this like what git calls an octopus? I've been wondering what the
point of such things were.
Or maybe
Hi,
Quoting "Aidan Van Dyk" :
Sure, and we can all construct example where that move is both right and
wrong...
Huh? The problem is the file duplication. The move is an action of a
committer - it's neither right nor wrong in this example.
I cannot see any use case for seemingly random file
Aidan Van Dyk writes:
> * Markus Wanner [090602 10:23]:
>> You consider it a mess, I consider it a better and more valid
>> representation of the mess that CVS is.
> So much better that it makes the history as useless as CVS... I think
> one of the reasons people are wanting tomove from CVS to
Aidan Van Dyk escribió:
> * Markus Wanner [090602 10:23]:
>
> > # Bang, you suddenly have 'testfile' and 'movedfile', go figure!
> >
> > I leave it as an exercise for the reader to try the same with a single
> > historic origin of the file, as cvs2git does the conversion.
>
> Sure, and we can
* Markus Wanner [090602 10:23]:
> # Bang, you suddenly have 'testfile' and 'movedfile', go figure!
>
> I leave it as an exercise for the reader to try the same with a single
> historic origin of the file, as cvs2git does the conversion.
Sure, and we can all construct example where that move i
Hi,
Quoting "Marko Kreen" :
Not a problem for git I think
Knowing that git doesn't track files as "hard" as monotone, I
certainly doubt that.
- it assumes they are same if they have
same contents...
Why do you assume they have the same contents? Obviously these are
different branches,
* Markus Wanner [090602 09:37]:
> Marko already convinced me of -kk, I'm trying that with cvs2git.
Good ;-)
> I just really didn't want to care about keyword expansion. Besides
> lacking consistency, it's one of the worst misfeatures of CVS, IMNSHO.
> ;-)
Absolutely... And one of the reas
Hi,
Quoting "Aidan Van Dyk" :
Pick your poison (after all, it's CVS), either way, I think the 2 of
*us* are going to disagree which is best here ;-)
Marko already convinced me of -kk, I'm trying that with cvs2git.
But, which ever way (exact to -kk or exact to -kv), the conversion
should be e
* Markus Wanner [090602 07:08]:
> Hi,
>
> Quoting "Marko Kreen" :
>>> I don't care half as much about the keyword expansion stuff - that's
>>> doomed to disappear anyway.
>>
>> But this is one aspect we need to get right for the conversion.
>
> What's your definition of "right"? I personally pref
On 6/2/09, Markus Wanner wrote:
> Quoting "Marko Kreen" :
> > Btw this conversion seems broken as it contains random merge commits.
> >
>
> Well, that's a feature, not a bug ;-)
>
> When a commit adds a file to the master *and* then to the branch as well,
> cvs2git prefers to represent this as
Hi,
Quoting "Marko Kreen" :
This is Definitely Wrong (tm). You seem to be thinking that comparing
GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
main use-case. It is not. Browsing history and looking and diffs
between versions is. And expanded CVS keywords would be tota
Hi,
Quoting "Marko Kreen" :
Btw this conversion seems broken as it contains random merge commits.
Well, that's a feature, not a bug ;-)
When a commit adds a file to the master *and* then to the branch as
well, cvs2git prefers to represent this as a merge from the master
branch, instead of
On 6/2/09, Markus Wanner wrote:
> Quoting "Marko Kreen" :
> > > I don't care half as much about the keyword expansion stuff - that's
> > > doomed to disappear anyway.
> > >
> >
> > But this is one aspect we need to get right for the conversion.
> >
>
> What's your definition of "right"? I perso
Hi,
Quoting "Marko Kreen" :
I don't care half as much about the keyword expansion stuff - that's
doomed to disappear anyway.
But this is one aspect we need to get right for the conversion.
What's your definition of "right"? I personally prefer the keyword
expansion to match a cvs checkout
On 6/2/09, Marko Kreen wrote:
> On 6/1/09, Markus Wanner wrote:
> > a newish conversion with cvs2git is available to check here:
> >
> > git://www.bluegap.ch/
> >
> > (it's not incremental and will only stay for a few days)
Btw this conversion seems broken as it contains random merge co
On 6/1/09, Markus Wanner wrote:
> a newish conversion with cvs2git is available to check here:
>
> git://www.bluegap.ch/
>
> (it's not incremental and will only stay for a few days)
+1 for the idea of replacing CVS usernames with full names.
The knowledge about CVS usernames will be increasi
Alvaro Herrera writes:
> Tom Lane wrote:
>> I suppose this must be Dennis Björklund, but I didn't realize he
>> used to be a committer.
> IIRC he was given commit privs for translation files.
Ah, right, that does ring a bell now.
BTW, Markus: you do realize "thomas" is not me but Tom Lockhart?
Tom Lane wrote:
> Markus Wanner writes:
> > 'dennis' : ('Dennis??', ''),
>
> I suppose this must be Dennis Bj�rklund, but I didn't realize he
> used to be a committer.
IIRC he was given commit privs for translation files.
--
Alvaro Herrerahttp://www.Command
Markus Wanner writes:
> I'm missing the names and email addresses for these committers:
> 'barry' : ('barry??', ''),
Barry Lind, formerly one of the JDBC bunch, been inactive for awhile
> 'dennis' : ('Dennis??', ''),
I suppose this must be Dennis Björklund, but I didn't realize he
used
Hi,
a newish conversion with cvs2git is available to check here:
git://www.bluegap.ch/
(it's not incremental and will only stay for a few days)
For everybody interested, please check the committer names and emails.
I'm missing the names and email addresses for these committers:
'barry'
* Alvaro Herrera [090529 11:45]:
> Aidan Van Dyk wrote:
>
> > Yes, but the point is you want an exact replica of CVS right? You're
> > git repo should have $PostgreSQL$ and the cvs export/checkout (you do
> > use -kk right) should also have $PostgreSQL$.
> >
> > The 3 parsecvs errors were that
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> What was in the back of my mind was that we'd go around and mass-remove
> >> $PostgreSQL$ (and any other lurking tags), but only from HEAD and only
> >> after the repo conversion. Although just before it would be okay too.
>
Aidan Van Dyk wrote:
> Yes, but the point is you want an exact replica of CVS right? You're
> git repo should have $PostgreSQL$ and the cvs export/checkout (you do
> use -kk right) should also have $PostgreSQL$.
>
> The 3 parsecvs errors were that it *didn't* recognoze the strange
> $PostgreSQL
* Markus Wanner [090529 11:18]:
> Hi,
>
> Quoting "Aidan Van Dyk" :
>> * Markus Wanner [090529 11:06]:
>>> Comparison of the head of each branch between git and CVS (modulo CVS
>>> keyword expansion, which I've filtered out):
>>
>> How did you filter it out
>
> With perl some regexes.
>
>> and wi
Hi,
Quoting "Aidan Van Dyk" :
* Markus Wanner [090529 11:06]:
Comparison of the head of each branch between git and CVS (modulo CVS
keyword expansion, which I've filtered out):
How did you filter it out
With perl some regexes.
and without the filtering out, how does it do?
Uh.. why is
* Markus Wanner [090529 11:06]:
> Hi,
> Comparison of the head of each branch between git and CVS (modulo CVS
> keyword expansion, which I've filtered out):
How did you filter it out, and without the filtering out, how does it
do?
> I plan to compare the tags as well and test what branch they
Hi,
Quoting "Aidan Van Dyk" :
Ok, so seeing the interest in having a "good conversion", I took a stab at
parsecvs this afternoon, probably what I consider the leading "static"
conversion tool.
Here are some results from a conversion with cvs2git.
It takes about 10 minutes to run my old xeon.
On Fri, May 29, 2009 at 2:41 AM, Markus Wanner wrot> Hi,
> Quoting "Robert Haas" :
>> Why is this harder than I think it is?
>
> One of the simplest possible example is something like:
Thanks for the explanation, I understand it better now. I'm still
dismayed, but at least I know why I'm dismaye
On Thursday 28 May 2009 20:03:38 Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Right. Shall we try to spec out exactly what our conversion
> > requirements are? Here's a shot:
>
> [...]
>
> > Comments? Other considerations?
>
> Certainly sounds reasonable to me. I'd be reall
Hi,
Quoting "Robert Haas" :
That's not the best news I've had today...
Sorry :-(
To me they sound complex and inconvenient. I guess I'm kind of
mystified by why we can't make this work reliably. Other than the
"broken tags" issue we've discussed, it seems like the only real issue
should be
Hi,
Quoting "Robert Haas" :
That might work, but then we better be pretty darn confident that that
"fresh conversion" is actually correct. I'd rather have them going
side-by-side so that we can verify everything before shutting the old
system off.
I agree, as long as you take non-incremental
On Thu, May 28, 2009 at 3:56 PM, Aidan Van Dyk wrote:
> Ok, so seeing the interest in having a "good conversion", I took a stab at
Awesome!
> Much better!!!
>
> The REL8_0_0 branch seem funny yet:
> src/backend/po/ru.po | 8416 ++--
> src/backend/parse
* Aidan Van Dyk [090528 15:56]:
> Ok, so seeing the interest in having a "good conversion", I took a stab at
> parsecvs this afternoon, probably what I consider the leading "static"
> conversion tool.
> It takes about 10 minutes to run my old xeon.
>
> And a comparison between it's conversion
* Andres Freund [090528 16:07]:
>> BTW, can anyone comment on whether and how we can maintain the current
>> split between master repository (that's not even accessible to
>> non-committers) and a public mirror? If only from a standpoint of
>> security paranoia, I'd rather like to preserve that
Hi,
On 05/28/2009 06:19 PM, Tom Lane wrote:
I am hoping that git's cvs server emulation is complete enough that you
can commit through it --- anybody know? But that will be just a
stopgap.
Comitting is no problem - you can't tag, branch or merge through it
though (Not really surprisingly I thi
* Aidan Van Dyk [090527 17:22]:
> And actually looking at the history of the gpo repo, the branches are all
> messed up with "merges" and stuff that I'm not sure where they are coming
> from... 8.2, 8.3, and master(HEAD) are all the same as my gpo repo, but the
> back branchs are very bad...
O
On Thu, 28 May 2009, Tom Lane wrote:
Each released minor version tag must check out the same as from CVS, at
least back to some specified point (perhaps 7.4.0). I'd really prefer
to insist on that all the way back.
We'd all like to hope that conversion process that works for everything
back
1 - 100 of 165 matches
Mail list logo
