On Mon, Oct 4, 2010 at 6:02 PM, Laurens Van Houtven <[email protected]>wrote:

> 2010/10/4 Lluís Batlle i Rossell <[email protected]>:
> > On Mon, Oct 04, 2010 at 10:55:02PM +0200, Laurens Van Houtven wrote:
> > You can review against the trunk version it was updated from. As any
> DVCS,
> > fossil does not provide methods to guarantee that noone commited over the
> same
> > parent as you, so if that happens, you then will have to merge two heads
> of a
> > single branch. This is inherent in DVCS, and not related to your review
> process.
>
> Yeah I was kind of hoping there was a way of creating a diff for the
> entire branch that just combines the subsequent changes. Or some
> automagic way of doing this. I guess it's not much of a problem.
>

Perhaps I don't really understand your problem.  But reading the above, it
seems like you are making this way harder than it needs to be.

On the SQLite project (for which Fossil was written) when we encounter a
bug, we'll normally fix the problem directly in the trunk.  If it is a bug
that requires multiple check-ins to fix, then we might put the fix in a
branch.  But usually, a bug is fixed by a single check-in and it goes
directly into the trunk.

Let's suppose your fixes are always more complicated and that they need to
be in a separate branch.  Fine.  Here's an example of where we did just that
in SQLite:

     http://www.sqlite.org/src/timeline?r=bug-b351d95f9c

Notice that the bug-fix branch forked from the trunk at check-in
53f5cfe115.  And the bug-fix was completed at check-in 88b84bf18a.  So to
see a single diff that covers all changes in the bug-fix you can visit

     http://www.sqlite.org/src/vdiff?from=53f5cfe115&to=88b84bf18a&detail=1

Or from the command-line you can type:

     fossil diff --from 53f5cfe115 --to 88b84bf18a | open -f

(The "open -f " bit on the end only works on a mac - substitute whatever
other text viewer is appropriate for your preferred platform.)

Key points:  (1) You can create branches off of any point of the trunk you
want.  (2) You can merge those branches back into the trunk whenever you
like.  (You can merge the same branch multiple times and Fossil just deals
with it - unlike some other VCSes.)  (3)  The graphing feature of the UI
gives you a clear visual indication of what is going on so you can stay on
top of the situation.  (4)  You can diff between any two versions you like.

Maybe I'm just too close to the code to see the problem.  Maybe (likely) the
Fossil documentation needs to be improved to explain all of the above.  Or
(perhaps) I'm missing some key functionality that you need to work your
process.  Please provide feedback.  Your feedback and criticism helps to
make Fossil better.


>
> >> Is there a decent way of filtering tickets on the ones which are up
> >> for review and which ones aren't? In trac, I did this with tags; but
> >> fossil doesn't appear to have tags for tickets.
> > You can write your own queries for fossil, and your own fields in each
> ticket.
> > In the web Admin -> Ticket configuration you can find that.
>
> Oh, cool, thanks.
>
> >> Also what do you people use for code review? I can imagine using
> >> fossil diff for this, I guess. Ideas welcome.
> > I still have not moved our scripts from svn to fossil, but what we used
> to do
> > was prepare two checkout directories, one with the last trunk version
> merged in,
> > and the other with the branch to review. Then we used meld (meld.sf.net)
> to get
> > a diff while being able to edit the files.
> > Then we leave comments and commit in the branch with the review results.
> >
> > I wonder how difficult it will be in fossil to find "the version of the
> parent
> > branch last merged into a child branch".
>
> I will take a look at meld, thank you.
>
> > Regards,
> > Lluís.
>
> cheers
> lvh
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
D. Richard Hipp
[email protected]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to