[EMAIL PROTECTED] (Travis P) wrote in message news:[EMAIL PROTECTED]...
Misinforming the user on rename with local changes
[EMAIL PROTECTED]
news://news.gmane.org:119/[EMAIL PROTECTED]
Might be easier to read with a browser here:
http://svn.haxx.se/dev/archive-2004-11/index.shtml
Travis P wrote:
Thomas (Hallgren): Unfortunately, my efforts to get Thunderbird to do
something useful with that URL have been unsuccessful and I can't find
the thread on the (usable) mailing list archive ( don't use the
tigris.org archive; use http://svn.haxx.se/ ).
Thanks Travis. I'm not at
Tom Lane wrote:
... There aren't
any alternatives that are enough better than CVS to be worth the
changeover effort.
I've done some research over the last couple of days for a fairly big
project where we face the challenges of breaking up a monolith into
modules and consequently will be forced
Thomas Hallgren wrote:
GNU-Arch seems promising in some respects. It really can rename files
and track them using an id, but it doesn't run on Windows without
Cygwin (and even then not too well it seems). Personally I dislike the
fact that the author seems somewhat religious about free
On Nov 13, 2004, at 6:20 PM, Thomas Hallgren wrote:
Question about rename on [EMAIL PROTECTED]
news://news.gmane.org:119/[EMAIL PROTECTED]
Thomas (Hallgren): Unfortunately, my efforts to get Thunderbird to do
something useful with that URL have been unsuccessful and I can't find
the thread on
This doesn't really answer the question of what tool Postgres might
change to, but it seems that Subversion is a good tool one should
consider. And by golly, CVS is bad. Just consider the cons having
to forbid renames in all but the most necessary cases it just
invites cruft into any
Tom,
(I'm rather interested to know whether any other SCMs have a better
solution to this problem, and if so what it is. It's not obvious how
to do better.)
I've been working with a few SCM's and IMHO only one of them really
handles this really well. That's ClearCase. I'm well aware that
The intuitive understanding of a file is certainly something like a
file called 'baz.c' residing at 'foo/bar/', which contains the BAZ
subsystem. Now, when renaming/moving a file such an intuitive
understanding is partially lost. UI-wise that's a problem which I
haven't ever seen solved well.
Joerg Hessdoerfer wrote:
Advocacy
Yes, some do. At least SVN (Subversion) can handle moves very well, and
especially it doesn't loose history on moves/renames.
SVN holds it's repo entries in a database like 'filesystem', which can be
backed by BDB4 or flat files (as of 1.1).
SVN has proven to be
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Why not move it to src/tools, so no one gets the impression that it is
user code?
I thought about that earlier, but concluded it wasn't worth the loss of
CVS history.
I have counted
On Thu, 4 Nov 2004, Alvaro Herrera wrote:
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Why not move it to src/tools, so no one gets the impression that it is
user code?
I thought about that earlier, but concluded it wasn't worth the loss of
Marc G. Fournier [EMAIL PROTECTED] writes:
why would we lose CVS history? I can physically move the files in
/cvsroot to accomplish this ... just tell me what needs to move, and to
where ...
If you physically move the files, that would retroactively change their
placement in back versions,
On Thu, 4 Nov 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
why would we lose CVS history? I can physically move the files in
/cvsroot to accomplish this ... just tell me what needs to move, and to
where ...
If you physically move the files, that would retroactively change
On Thu, Nov 04, 2004 at 02:41:08PM -0500, Tom Lane wrote:
(I'm rather interested to know whether any other SCMs have a better
solution to this problem, and if so what it is. It's not obvious how
to do better.)
I understood that the whole point of subversion was mostly to make
moving files
Tom Lane wrote:
AFAICS the only nondestructive way to do this is to cvs delete and cvs
add, with a commit comment saying where the files were moved from. Then
when you are looking at them in CVS, you'd have to navigate over to the
previous location (by hand, probably; the commit comment isn't
Hi,
On Thursday 04 November 2004 20:41, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
why would we lose CVS history? I can physically move the files in
/cvsroot to accomplish this ... just tell me what needs to move, and to
where ...
If you physically move the files, that
On Fri, 5 Nov 2004 07:02 am, Marc G. Fournier wrote:
On Thu, 4 Nov 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
why would we lose CVS history? I can physically move the files in
/cvsroot to accomplish this ... just tell me what needs to move, and to
where ...
If
Neil Conway wrote:
[CC list trimmed]
On Fri, 2004-11-05 at 06:41, Tom Lane wrote:
(I'm rather interested to know whether any other SCMs have a better
solution to this problem, and if so what it is. It's not obvious how
to do better.)
Sure -- just about every next generation OSS version control
18 matches
Mail list logo