RB coming with new version control support?
Thomas Tempelmann ,
home-baked, very simple version control server.
The RB 5.x IDE had commands to store project items on that server and
retrieve them again.
Its limitations were, though (IIRC):
- could not store multiple versions, i.e. a history, of changes but
only the last incarnation of each project item.
- could not show you changes between the stored version and your
current local changes
With the version control system I've built, these limitations are gone.
Now, I've heard rumours of RB soon having its own new version control
support. It's supposed to use a commonly used server such as
Subversion.
I wonder how it shall work, though:
- will it store the items in the usual binary or in xml format? if so,
seeing changes (diffs) between versions will still be hard, compared to
the new text format I've introduced with my tool.
- there needs to be a way to see differences, especially if one has
created conflicts because two local copies have both made changes to
the same part of source code. how shall that work? will the IDE provide
its own user interface to view the changes and edit them? that would be
perfect as then we could care less what format it's using with
subversion. But if not, how shall this work out for us users?
Does anyone know more about this or has a good enough contact to RS to
at least raise awareness of these possible complications?
I like to prevent them from making yet another half-baked attempt at it
(they're surely not immune to it, after all, just see their odyssee
with their DBs as an example, or the awkward "finally" statement that
has been implemented without fully understanding how it's _supposed_ to
work)
It's really sad that RS is not openly discussing such features BEFORE
they go to implement it, and so it's up to us to try to talk to them in
private if you have a connection to them.
BTW, I'd be glad to see that they solve this properly, as I could stop
writing my own then, but for now I'm not too optimistic they'll do a
thorough job on it. If you know enough to put me at ease, please let me
know (confidentially).
Thomas
Ed Kleban
On 1/27/06 8:20 AM, "Thomas Tempelmann ," <tempe...@gmail.com> wrote:
> BTW, I'd be glad to see that they solve this properly, as I could stop
> writing my own then, but for now I'm not too optimistic they'll do a
> thorough job on it. If you know enough to put me at ease, please let me
> know (confidentially).
>
> Thomas
I can't recall a single time that RS has implemented something in a manner
that made me exclaim. "Fantastic! This is perfect. Just the way I would
have done it." There's usually a wide gap between my expectations and the
end result. Especially during early releases -- which can often mean "the
first few years".
Thomas Tempelmann
just pointed it out to explain why I think the version control plans
of RS should involve us in the discussion.
Now, how do we accomplish this?
Dr. Scott Steinman
shape the version control tools. For example, I'd like to see BOTH
version control tools for multi-programmer projects that can be used
over the internet and for single programmers that can be used with a
local repository on their own computer.
-Scott
Scott B. Steinman, O.D., Ph.D., F.A.A.O.
Professor, Southern College of Optometry
Chair, Open Source Purely-Graphical Programming Language Initiative
(www.ospgli.org)
Author, "Visual Programming with Prograph CPX", Manning/Prentice-
Hall, 1995 (www.manning.com/steinman).
Author, "Foundations of Binocular Vision", McGraw-Hill, 2000
(books.mcgraw-hill.com/cgi-bin/pbg/0838526705.html)
Brought to you by a grant from the Steinman Foundation (Thanks, Mom
and Dad!)
Recommended by Major University Studies Over the Leading Brand
1245 Madison Avenue
Memphis, TN 38104-2222
steinman at sco.edu
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken
Nothing is impossible for the man who doesn't have to do it himself.
-- Anonymous
Ed Kleban
On 1/27/06 1:05 PM, "Thomas Tempelmann" <tempe...@gmail.com> wrote:
>
> Yes, but I do not want this to become another RS-bashing thread.
Agreed.
> I
> just pointed it out to explain why I think the version control plans
> of RS should involve us in the discussion.
That's nice, but beyond our control. If I were RS I'd probably do the exact
same thing.
> Now, how do we accomplish this?
Same way you have been so far. Just keep adding functionality. You've been
lucky that for the most part you've been able to bite off small simple
chunks to deal with. At some point you'll probably have to invest in a more
ambitious endeavor if you want a big, sophisticated, integrated solution.
We can certainly brainstorm here as to what the "right thing" should be. At
the very least we can hope someone(s) from RS are participating in the
discussion here, at least as lurkers. At the very best you end up releasing
a product with superior functionality or feature set that's better than what
RS comes up with pressuring them to either adopt the features that you've
provided or have to compete with a solution in the market that's recognized
to have significant merit.
A large part of my motivation in developing REALinsight was just that... to
get something out there that implemented my own view of the "right thing"
for others to stare at, play with, and use and therefore provide yet another
source of pressure to nudge RS in a direction I'd love to seem them move in
a lot faster. But first and foremost, my reason for working on RI is I need
the functionality myself.