What's up

[Daniel Scott Matthews]

On Tue, Jul 14, 2009 at 2:51 PM, Timothy M. Shead<tshead@...> wrote:
> ... is out there.  The best place to start is at the new
>
> http://www.k-3d.org/wiki/Code
>
> page in the wiki.
>

I just grabbed a built a copy of Tim's repository on a Ubuntu 64
system, it works very smoothly and you can use Google Reader and the
RSS feeds Mercurial provides (e.g.
http://bitbucket.org/tshead/k3d-sandbox/rss/) to keep an eye on when
you may need to pull new changes down to your local copy and rebuild.

http://www.google.com.au/search?q=Mercurial%3A+The+Definitive+Guide

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Daniel Scott Matthews wrote:

> On Tue, Jul 14, 2009 at 2:51 PM, Timothy M. Shead<tshead@...> wrote:
>> ... is out there.  The best place to start is at the new
>>
>> http://www.k-3d.org/wiki/Code
>>
>> page in the wiki.
>>
>
> I just grabbed a built a copy of Tim's repository on a Ubuntu 64
> system, it works very smoothly and you can use Google Reader and the
> RSS feeds Mercurial provides (e.g.
> http://bitbucket.org/tshead/k3d-sandbox/rss/) to keep an eye on when
> you may need to pull new changes down to your local copy and rebuild.

One caveat now that I'm looking at it for the first time - the RSS feed
seems to be out-of-date.  I've reported a bug to bitbucket, in the
meantime you may want to look at the repository home-page, which does
have the latest:

http://bitbucket.org/tshead/k3d-sandbox

... there's a change there that will be of interest to you ;)

Cheers,
Tim

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Daniel Scott Matthews]

On Wed, Jul 15, 2009 at 12:24 AM, Timothy M. Shead<tshead@...> wrote:

> Daniel Scott Matthews wrote:
>>
>> On Tue, Jul 14, 2009 at 2:51 PM, Timothy M. Shead<tshead@...> wrote:
>>>
>>> ... is out there.  The best place to start is at the new
>>>
>>> http://www.k-3d.org/wiki/Code
>>>
>>> page in the wiki.
>>>
>>
>> I just grabbed a built a copy of Tim's repository on a Ubuntu 64
>> system, it works very smoothly and you can use Google Reader and the
>> RSS feeds Mercurial provides (e.g.
>> http://bitbucket.org/tshead/k3d-sandbox/rss/) to keep an eye on when
>> you may need to pull new changes down to your local copy and rebuild.
>
> One caveat now that I'm looking at it for the first time - the RSS feed
> seems to be out-of-date.  I've reported a bug to bitbucket, in the meantime
> you may want to look at the repository home-page, which does have the
> latest:
>
> http://bitbucket.org/tshead/k3d-sandbox
>
> ... there's a change there that will be of interest to you ;)
>

I have used that change to hand edit a lights.lxs to add the
LightGroup attribute so that I could product the following examples,
from a single render.

http://www.k-3d.org/wiki/User:Dsmatthews/LuxRender/lights/LightGroup

The wiki is messing up my code listing, but you can still see how it works.

N.B. you need to use the luxrender GUI the edit LightGroup values, not
luxconsole.

The original scene was one that I put together to test the different
LuxRender material types, using light groups allows you to understand
how your materials will look in different lighting scenarios, and for
some materials the difference is significant.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Tue, Jul 14, 2009 at 6:51 AM, Timothy M. Shead<tshead@...> wrote:
> ... is out there.  The best place to start is at the new
>
> http://www.k-3d.org/wiki/Code

OK, I've rebased my repository on the sf.net repository. The most
notable changes in there are:
- The mesh module compiles again and is ON by default
- There is now basic TAB-completion in the Python shell

I'll revisit the ATK stuff after looking into Daniel's SVG problem.

Cheers,

--
Bart

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Tue, Jul 14, 2009 at 6:51 AM, Timothy M. Shead<tshead@...> wrote:
>> ... is out there.  The best place to start is at the new
>>
>> http://www.k-3d.org/wiki/Code
>
> OK, I've rebased my repository on the sf.net repository. The most
> notable changes in there are:
> - The mesh module compiles again and is ON by default
> - There is now basic TAB-completion in the Python shell
>
> I'll revisit the ATK stuff after looking into Daniel's SVG problem.

Merged into the main repository - very smooth!  The only thing that I
think we should be shooting-for as we move ahead is using repositories
to group feature-related changes together.  For example: I'm wishing I
had started a separate repository for all the LuxRender changes ... the
notion being that Daniel and I would be able to easily collaborate, and
anyone interested could follow-along, but that all the LuxRender changes
could be moved into the "official" repository in one fell swoop.  Food
for thought ...

Cheers,
Tim

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, Jul 9, 2009 at 6:43 AM, Timothy M. Shead<tshead@...> wrote:
> * Changes must be rebased before posting - i.e. it's up to the dev to
> handle merge conflicts.  Rebasing is your friend - it eliminates the
> many annoying "merged with revision foo" messages that otherwise clutter
> the repository.

Well, I'm sorry, but rebasing is no longer my friend. I tried to
rebase before commiting yesterday, but the rebased repo could no
longer be pushed to my google code repository, since that would create
multiple heads. All attempts to solve this resulted in multiple
occurances of the same changeset. I spent almost an hour trying to get
this fixed, with rebase prompting me to resolve merge conflicts every
step of the way. Finally, I gave up and tried a merge, which was
simpler: it popped up the conflict window only once, and it was
immediately clear that all I had to do was replace
k3d::geometry::merge_selection with k3d::geometry::selection::merge.
That change is captured in changeset
http://code.google.com/p/k3d-bart/source/detail?r=5014ee76b7ee101faa5c44abdaae48b6c362a0b

I also don't know how to resync with the current sf.net repository: no
matter what I do (rebase or merge), I seem to end up with two copies
of my changes to NurbsExtrudeCurves.

I propose that when there is a conflict between changes, as was the
case here because of the renaming of merge_selection, we do a merge
instead of a rebase. This is much simpler, and preserves the actual
evolution of the changes.

Cheers,

--
Bart

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Wed, Jul 22, 2009 at 1:43 PM, Bart Janssens<bart.janssens@...> wrote:
> I also don't know how to resync with the current sf.net repository: no
> matter what I do (rebase or merge), I seem to end up with two copies
> of my changes to NurbsExtrudeCurves.

I can confirm that I'm getting nowhere here. The only solution I see
at this point is to nuke my google code repository and to upload a new
version based on the sf.net repository. If anyone finds a way to merge
the sf.net and google code repositories without duplicate changesets
and in such a way that it's up-to-date with both repositories, please
let me know ;)

Note that nuking the repository has no real bad side-effects, since
it's only a sandbox.

Cheers,

--
Bart

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Wed, Jul 22, 2009 at 1:43 PM, Bart Janssens<bart.janssens@...> wrote:
>> I also don't know how to resync with the current sf.net repository: no
>> matter what I do (rebase or merge), I seem to end up with two copies
>> of my changes to NurbsExtrudeCurves.
>
> I can confirm that I'm getting nowhere here. The only solution I see
> at this point is to nuke my google code repository and to upload a new
> version based on the sf.net repository. If anyone finds a way to merge
> the sf.net and google code repositories without duplicate changesets
> and in such a way that it's up-to-date with both repositories, please
> let me know ;)

If you take a look at

http://k3d.hg.sourceforge.net/hgweb/k3d/graph

... you will see that I rebased your changes to keep the history in the
"official" repository tidy.  There are varying opinions on whether or
not this is the right thing to do, so I started a wiki page to collect some:

http://www.k-3d.org/wiki/Rebase_Versus_Merge

if anyone finds some good, well-thought-out, scholarly discussions on
this topic, please add them to the list.  My current rule-of-thumb is
that it's better to have a messy developer repo and a tidier official
repo, but that's hardly set in stone.

When you (or me, in this case) rebase, your changesets are modified -
they now have different parents.  That makes them "different"
changesets, so when you pull from the central repo, the rebased
changsets are a new branch in your repo.  You can ignore the old csets,
or you can use "hg strip" to remove old branches that are obsolete, if
they bug you - if you choose the strip option, be careful - it can be
reversed, but reversing it requires a little digging ;)  This is why
it's better if you do it before I pull.

This stuff takes some getting used-to, but I'm starting to get into the
spirit of it ...

Cheers,
Tim


------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, Jul 23, 2009 at 7:32 AM, Timothy M. Shead<tshead@...> wrote:
> http://www.k-3d.org/wiki/Rebase_Versus_Merge
>
> if anyone finds some good, well-thought-out, scholarly discussions on
> this topic, please add them to the list.  My current rule-of-thumb is
> that it's better to have a messy developer repo and a tidier official
> repo, but that's hardly set in stone.

OK, looking at the first link from the wiki page clarified things for
me. The problem was that an already pushed changeset got rebased. We
should only rebase changesets that haven't been pushed to public
repositories. I've reset my repository to the sf.net version.

Cheers,

--
Bart

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Thu, Jul 23, 2009 at 7:32 AM, Timothy M. Shead<tshead@...> wrote:
>> http://www.k-3d.org/wiki/Rebase_Versus_Merge
>>
>> if anyone finds some good, well-thought-out, scholarly discussions on
>> this topic, please add them to the list.  My current rule-of-thumb is
>> that it's better to have a messy developer repo and a tidier official
>> repo, but that's hardly set in stone.
>
> OK, looking at the first link from the wiki page clarified things for
> me. The problem was that an already pushed changeset got rebased. We
> should only rebase changesets that haven't been pushed to public
> repositories. I've reset my repository to the sf.net version.

Agreed!
Tim


------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Thu, Jul 23, 2009 at 7:32 AM, Timothy M. Shead<tshead@...> wrote:
>> http://www.k-3d.org/wiki/Rebase_Versus_Merge
>>
>> if anyone finds some good, well-thought-out, scholarly discussions on
>> this topic, please add them to the list.  My current rule-of-thumb is
>> that it's better to have a messy developer repo and a tidier official
>> repo, but that's hardly set in stone.
>
> OK, looking at the first link from the wiki page clarified things for
> me. The problem was that an already pushed changeset got rebased. We
> should only rebase changesets that haven't been pushed to public
> repositories. I've reset my repository to the sf.net version.

So, I'm still learning too, and just ran across a problematic use-case
that makes thing less clear-cut ;)  I've documented it at

http://www.k-3d.org/wiki/Rebase_Versus_Merge

... in a nutshell, with rebase you can do everything right and still
leave the repo in an uncompilable state, whereas an explicit merge can
leave the repo compilable at every point in its history.  So it comes
down to a question of what people value most: clean, linear repo
history, or trying to never break the build.  As obsessive as I am with
cleanliness, I have to say that I lean towards favoring the build.

Cheers,
Tim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sat, Aug 1, 2009 at 5:06 AM, Timothy M. Shead<tshead@...> wrote:

> Bart Janssens wrote:
>> On Thu, Jul 23, 2009 at 7:32 AM, Timothy M. Shead<tshead@...> wrote:
>>> http://www.k-3d.org/wiki/Rebase_Versus_Merge
>>>
>>> if anyone finds some good, well-thought-out, scholarly discussions on
>>> this topic, please add them to the list.  My current rule-of-thumb is
>>> that it's better to have a messy developer repo and a tidier official
>>> repo, but that's hardly set in stone.
>>
>> OK, looking at the first link from the wiki page clarified things for
>> me. The problem was that an already pushed changeset got rebased. We
>> should only rebase changesets that haven't been pushed to public
>> repositories. I've reset my repository to the sf.net version.
>
> So, I'm still learning too, and just ran across a problematic use-case
> that makes thing less clear-cut ;)  I've documented it at
>
> http://www.k-3d.org/wiki/Rebase_Versus_Merge
>
> ... in a nutshell, with rebase you can do everything right and still
> leave the repo in an uncompilable state, whereas an explicit merge can
> leave the repo compilable at every point in its history.  So it comes
> down to a question of what people value most: clean, linear repo
> history, or trying to never break the build.  As obsessive as I am with
> cleanliness, I have to say that I lean towards favoring the build.

Assuming D and E are private (unpushed) changesets,  I think a
possible solution here would have been to insert F after C, and then
rebase D on F. Of course it's more work, since you will only find out
about the conflict after first trying a normal rebase.

I've also merged my repository with sf.net, since I had already pushed
some changes that could not be rebased. These included the bad fix for
the RenderMan NURBS patch painter. This gave a conflict, which I
resolved in favor of the sf.net repository. The advantage of a merge
here is that the changeset remains in the history, and the link posted
here on the mailing list should remain valid.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> On Sat, Aug 1, 2009 at 5:06 AM, Timothy M. Shead<tshead@...> wrote:

>> So, I'm still learning too, and just ran across a problematic use-case
>> that makes thing less clear-cut ;)  I've documented it at
>>
>> http://www.k-3d.org/wiki/Rebase_Versus_Merge
>>
>> ... in a nutshell, with rebase you can do everything right and still
>> leave the repo in an uncompilable state, whereas an explicit merge can
>> leave the repo compilable at every point in its history.  So it comes
>> down to a question of what people value most: clean, linear repo
>> history, or trying to never break the build.  As obsessive as I am with
>> cleanliness, I have to say that I lean towards favoring the build.
>
> Assuming D and E are private (unpushed) changesets,  I think a
> possible solution here would have been to insert F after C, and then
> rebase D on F. Of course it's more work, since you will only find out
> about the conflict after first trying a normal rebase.

This is highly dependent on the nature of the change - I updated the
example to match the situation I encountered a little more closely -
notice that in the updated diagram, F cannot precede D.

Regardless, I think the takeaway is that on some level the repo has to
reflect the actual path of development, if it's always going to compile.
  My new rule-of-thumb is that I'm going to continue to rebase when I
know there aren't any conflicts, and merge otherwise.

Cheers,
Tim


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Mon, Aug 3, 2009 at 6:20 AM, Timothy M. Shead<tshead@...> wrote:
> Regardless, I think the takeaway is that on some level the repo has to
> reflect the actual path of development, if it's always going to compile.

True, and with rebase you change that path, if there are conflicts.

>  My new rule-of-thumb is that I'm going to continue to rebase when I
> know there aren't any conflicts, and merge otherwise.

Well, I just did it wrong again, and merged when I didn't have to. I
noticed too late that I could have done a rebase locally after the
merge, and then push to the public site. From now on, I'm always going
to merge first, and if the merge changeset is empty, rebase locally
before pushing to a public site.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development