>> I'm relatively new here, but AFAIK there are two initiatives,
>> I'm building a windows dedicated one, and there's a wxWindows
>> version (*forgive my ignorance but I am bad with names*) in
>> the works (discussed some time ago).
>
> Could you provide some info (or links) about this two initiatives?
I cannot comment too much about the wxWindows one, I had hoped the
original developer would kick in and correct me.The one I'm working on, quite briefly, has the following featureset :
- Multiple document interface.
- Working set hierarchy in tree control on the left.
- Visual File Merge/diff functionality for conflicts.
- Syntax Hilighted sourcecode display for popular formats.
..
Hence me calling it 'ambitious' and 'prone to failure' (3 out of 4 bullets
are, technically speaking, not essential)..
Initial version will have all of these in a very bare bones manner.
(Development order is from bottom to top btw.).
>> > I'm asking this, because I don't want to start another
>> > GUI, if there is already someone working in one.
>> Imho, given the high risk of failure when starting to build
>> something from scratch (loss of interest, other things
>> demanding attention etc. etc.), the more initiatives the
>> merrier, but that's just me. What I'm working on is rather
>> ambitious so more prone to failure. I hope everyone agrees....?
>
> I think that you're right! It's better to put some team effort
> in a project than starting to create several simmilar projects
> that disperses "man power".
Now please, don't get me wrong here - I'm no expert, but I think this is
the exact opposite of what I meant. My point was that having multiple
projects running concurrently breeds competition and commits ego of the
developers thus improving the chances of any one initiative succeeding and
due to the ego commit accellerating the development of them all.Coordinating work among / maximizing use of multiple people (in my ever so
humble opinion) is a valid concern, but only when the project is too large
to encompass for a single person; a client is not (I think/hope), and
having multiple people bring one client to critical mass would (I
think/expect) introduce considerable effort/morale thrashing in hashing
out a design. I think this is different if there is strong leadership (but
that's difficult on what would still be vaporware) or corporate backing..
But then again, who am I?
..
My plan, quite briefly, is the following :
- Get merge/diff preview tool out (without svn integration, but designed
for it (internally and GUI complete) - get 2nd opinions on GUI, concepts,
when it's still easy to make modifications etc. etc.)- Add svn support (I thought delaying this bit was a 'good idea' as there
are still discussions going on things that 'scare me' from a change
control perspective on this list (but then maybe I'm easily 'scared' and
need to entrench myself deeper into the realms of svn)).- at the point that this works 'somewhat', share code, as I then think we
have critical mass..
> What I would like? I would like to create a Subversion GUI like
> TortoiseCVS (I myself use it), because I think it's simple and
> easy to use.
Seen TortoiseCVS, was also discussed here, looks good.
..
> Regards,
> Fernando Silva
Cheers, Martijn Boekhorst.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:11:52 2002