9.0 was stagnant. The 9.1 will now correctly build for 9.0. A newbie looking for their
Mandrake 9.0 will not know this.
I didn't know if someone would be upset if I removed it. And since Mandrake 9.0 is
still vialble, I did not think it was time yet to remove it.
The same could be said of redhat-7+.
Mandrake 9.2 will use different revision numbers and packages have moved around. I
cannot have just one version to compile them all at the moment. At some point this
may become possible.
I didn't realize that the branches could not be used to test.
My issue is that the trunk compiles with different versions of the stock libraries (0.24.0
vs 0.23.0.
I really didn't see anything wrong w/ having a centralized point from which to make a
version that successfully compiles at the very least the current stable branch 0.29.0,
as well as the trunk.
Should somoene who does not yet have 0.24.x of neon want to compile 0.29.0, the
way I have been constructing the Mandrake packages could simply drop the entire
directory on top of their stock 0.29.0 tree in the correct place and it would compile
correctly for 0.29.0.
To this end, I have been trying not to modify the trunk until I can verify what is different
between the two and only then doing so with care.
Everywhere I worked before my present job, we've always had 4 environments.
So when I took the current position at my current place of employment, we deployed
the same 4 environments. A development branch. A unit test branch. A system test
branch. And a production branch. The development and unit test branches do not need
to successfully compile. And they need to emulate each other closely.
The production and system test branches operate similarly. People can do what they
want without stepping all over each other. And production is always golden.
Since no one bothered to explain to me how many toes I might be stepping on, I
opted for the least impact. I treated the trunk as system test. I treated the tags as
production. And I treated the branches as development/unit test.
Since I work at home on subversion and sometimes from work, there needed to be a
way for me to transmit changes in-progress that might not compile successfully. So I
was using the branches to carry that out.
I am also used to keeping an offisite copy up to date so work is not lost, hence I
commit to the branch when I need to save intermediate results.
Being the new kid on the block, perhaps it's best if you *tell* me how you want me to
treat the branches.
I am not used to an environment where you can commit to the trunk when something
is in flux and not ready for production.
And I need to know how to handle my 2 different working environments.
Is there a private repository I should set up? What would you advise?
I guess I'm just not understanding the issue because according to subversion's
documentation, trees are cheap copies and occupy almost no space.
I've only been trying to follow good development protocol as best as I know how.
Obviously there are many ways to skin a cat.
Tell me how things should be and I will comply.
Shamim Islam
BA BS
Greg Stein (gstein@lyra.org) wrote:
>
>On Mon, Sep 22, 2003 at 04:00:27PM -0500, kellin@tigris.org wrote:
>> Author: kellin
>> Date: Mon Sep 22 16:00:26 2003
>> New Revision: 7143
>>
>> Added:
>> trunk/packages/rpm/mandrake-9.0/
>> - copied from rev 7135, trunk/packages/rpm/mandrake-9.1/
>>...
>> trunk/packages/rpm/mandrake-9.2/
>> - copied from rev 7135, trunk/packages/rpm/mandrake-9.1/
>
>If the 9.0 and 9.2 directories are just simple copies of 9.1, then why do
>they exist at all?! Why not just rename the directory to 9.x and be done
>with it?
>
>I'm also not a big fan of the branch development that you're doing.
>Merging back and forth; creating and deleting branches. Just fix the
>packaging issues right in trunk. There isn't any need to have an "rpm
>test" branch. Don't test things in source control. Test them on your
>machine; when they work, check them into the trunk.
>
>Cheers,
>-g
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 05:12:23 2003