> From: Files [mailto:files@poetryunlimited.com]
> Sent: Tuesday, September 23, 2003 5:12 AM
[...]
> 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.
[...]
> 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.
When not sure, ask!
> 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.
You've created at least 2 branches: 'mdk-test' and 'silent'. Surely you could
have done the silent build testing in your working copy.
> 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.
We don't do that. trunk must compile, work and pass the test suite at all
times.
> 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?
Anyway that solves your problem without cluttering our inboxes with commit
mails. Be that putting things on a laptop, floppy disk, sending by mail,
putting it on a local fileserver, a local copy of subversion, ...
> I guess I'm just not understanding the issue because according to subversion's
> documentation, trees are cheap copies and occupy almost no space.
Copies are cheap, yes. Peoples time however, is not. And when I see branches
being created and big blocks of commit from one person, my personal alarm bell
tells me to watch what is going on. I am very comfident that I am not alone in
this.
> 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.
At the very least, read HACKING.
> Tell me how things should be and I will comply.
The usual course of action new committers take is to watch how things work.
Basically all committers came in after they had already produced a few
patches and been around for a while. We decided to lower the bar for
commit access on the non-core code, expecting the old trend to continue.
Maybe that was a mistake, I don't know.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 11:14:07 2003