I agree to ur point.
If Revision Graph is all awe need then we can very well think of GEF/draw2D.
I suggested EMF-GMF because with the Revision GRaph you will get lot other
features, say for eg: u can simply tweak around the graph to figure out
possible commits and the pending work you have for your next release. Its
something like forecasting. (I might be wrong .. but its just an
brainstorming Idea :)
When we use GEF the number of features that we want can be very well decided
I went thru the Subversion branching & merging features. This task is very
The books says branching is something similar to hard link. So is it not
possible to track down the parent link and go on finding where exactly
branch started ??
BTW one more query. I am going to submit an Application for this project. So
do you expect me to give you the alogrithm which we will use to determine
brances & merging and how exactly we ll get the info to generate the graph.
On Wed, Mar 19, 2008 at 7:20 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> You need to use Reply to All so that mails go to the dev@ list.
> You should be looking at GEF/Draw2D for this. EMF and GMF would be
> overkill and drag in dependencies we do not want.
> For svn log, keep in mind that we run a JavaHL API that gives us that
> data in Java. So do not think you have to process the log output from
> a file or something.
> The main part of this task will probably be defining the algorithms
> you are going to use to determine the branches and tags for a given
> On Tue, Mar 18, 2008 at 10:32 PM, Amit Surana <amitsurana1_at_gmail.com>
> > Thats cool. Being in India I couldnt attend EclipseCon. Do share your
> > experience with me.
> > I looked at tortoiseSVN revision graph. It is pretty similar to what I
> > in mind.
> > Possibly a small gist of idea can be that we can construct a MetaModel
> > Eclipse's EMF that houses all the information we require to view on the
> > graph and these can be mapped directly to GMF so that a beautiful canvs
> > comes up with all the info required.
> > (This is a naive idea. Eclipse does provide u with rich frameworks that
> > be used to create such Graphs very quickly.)
> > Since logs are our only source of info, we can process them and get info
> > about the branches & merges.
> > How about this idea ?
> > I 'll dig more into the subversion details and get back to u. I va
> > knowledge in SVN right now.
> > On Wed, Mar 19, 2008 at 10:14 AM, Mark Phippard <markphip_at_gmail.com>
> > >
> > > On Tue, Mar 18, 2008 at 1:56 AM, Amit Surana <amitsurana1_at_gmail.com>
> > wrote:
> > >
> > > > I read the idea "revision graph" posted in GSoc page.
> > > > I need more details regrading this.
> > > > I am a CS engineering student from India. having worked on Eclipse
> EMF &
> > > > GMF, I did like the idea.
> > > > AFAI understood subclipse need a "revision graph" tool that will
> > > > graphically represent details of every folder/file with appropriate
> > commit
> > > > dates, committers, time stamp, etc
> > >
> > > Thanks for expressing interest. A lot of us are at EclipseCon this
> > > week, so do not have a lot of time for email. The best thing would be
> > > to look at the feature in TortoiseSVN as an example. Basically, it is
> > > sort of showing the history for a selected folder/file, with the
> > > exception that it is showing you things that History does not show,
> > > such as branches and tags that have been created, and then the history
> > > on those locations. Ideally it would also show the merges that
> > > occurred between these paths, but that would really be a secondary
> > > feature that could come later.
> > >
> > > The hard part of this task is really that Subversion does not have
> > > this information readily available. When you make a branch from trunk
> > > in SVN, trunk does not know about the branch. So something needs to
> > > be done to figure out that information.
> > >
> > > --
> > > Thanks
> > >
> > > Mark Phippard
> > > http://markphip.blogspot.com/
> > >
OPEN SOURCE: No Bill, No Gates, No Windows, Its open
Received on 2008-03-21 12:51:37 CET