[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] GSoc - Revision Graph

From: Amit Surana <amitsurana1_at_gmail.com>
Date: Fri, 21 Mar 2008 17:58:00 +0530

Hi,
I found another info regarding branches. As we know branches are created in
the middle of main development line.
So is it not possible by us to find trace the "missing" revision numbers in
main development line.

By "Missing" revision numbers I mean that when a branch commits change the
revision number increases but its not visible in the log of main development
line.

Eg:
Say You have a main development line (Trunk) from revision 0 to revision
100.
When branch is created revision number changes to 101.
Hence after r101, there might be many missing revision numbers in Trunk.
This clearly shows that there exist some branch that is also commiting
changes.

Is my analogy correct ??

On Fri, Mar 21, 2008 at 5:21 PM, Amit Surana <amitsurana1_at_gmail.com> wrote:

> Hi
> 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 upon.
>
> I went thru the Subversion branching & merging features. This task is very
> well solvable.
> 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
> > item.
> >
> > Mark
> >
> >
> > On Tue, Mar 18, 2008 at 10:32 PM, Amit Surana <amitsurana1_at_gmail.com>
> > wrote:
> > > 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
> > had
> > > in mind.
> > > Possibly a small gist of idea can be that we can construct a MetaModel
> > using
> > > 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 can
> > > 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
> > limited
> > > knowledge in SVN right now.
> > >
> > >
> > >
> > >
> > > On Wed, Mar 19, 2008 at 10:14 AM, Mark Phippard <markphip_at_gmail.com>
> > wrote:
> > >
> > > >
> > > > 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/
> > > >
> > >
> > >
> > >
> > >
> > >
> >
>
> --
> Regards,
> Amit
>
> http://suranaamit.blogspot.com/
> OPEN SOURCE: No Bill, No Gates, No Windows, Its open
>

-- 
Regards,
Amit
http://suranaamit.blogspot.com/
OPEN SOURCE: No Bill, No Gates, No Windows, Its open
Received on 2008-03-21 13:28:09 CET

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.