On 09/03/11 04:14, William Zwicky wrote:
>
> And 3a is the best simply because one should stay away from merging wherever
> possible. And it's pretty much free, since it's always good to create a tag
> for every version that is released.
>
Or use mercurial/git because they do a slightly better job
On Fri, Sep 2, 2011 at 6:23 PM, Joe Emenaker wrote:
> 3a) Branch off 2.0 and let bug-fixing happen there while new features
> and development toward 3.0 happen in trunk.
> 3b) Branch off a copy of trunk for work on 3.0, while the bug fixes
> for 2.0 happen in trunk. When 2.0 is released, a tag
On 09/02/2011 10:13 AM, Vladimir Avdonin wrote:
> Well, I have different phylosophy - I believe no development shall
> happen trunk, it shall stay clean and functional at any moment.
That sounds like you're saying that, at all times, checking out from
trunk should give you a release. That's differ
On Fri, Sep 2, 2011 at 10:13 AM, Vladimir Avdonin wrote:
> Well, I have different phylosophy - I believe no development shall
> happen trunk, it shall stay clean and functional at any moment. The only
> commits that shall go there should be from tested working branch.
> ...
> What if we do not wa
> it shall stay clean and functional at any moment.
If only clean stuff is commited this would still be possible.
> What if we do not want to go back? Breaking up things is inevitable in
> process of changing. And broken period can take extended time.
We could still use a refactoring branch.
On 09/02/2011 11:57 AM, Joachim wrote:
> Ah, I don't think it makes sense to make a branch for every bug.
Not every bug, just complicated ones, involving non-obvious changes and
requiring extensive testing
>
> > and it might be not clear at start towards what release it
> > will be targete
Ah, I don't think it makes sense to make a branch for every bug.
> and it might be not clear at start towards what release it
> will be targeted
The target release is not a problem if the development takes place
in the trunk.
> it probably would break everything in the project
Remember: We c
On 09/02/2011 11:25 AM, Joachim wrote:
> Hi,
>
> > I could think of three directories: fixes, features, users.
>
> Normally branches are made for different releases. I don't see
> a benefit in these three suggested branches as bug fixes have to
> be merged with new features anyway. The users bra
Hi,
> I could think of three directories: fixes, features, users.
Normally branches are made for different releases. I don't see
a benefit in these three suggested branches as bug fixes have to
be merged with new features anyway. The users branch is a concept
I didn't get.
trunk is the somehow
On 09/02/11 02:06, Vladimir Avdonin wrote:
> On 09/01/2011 07:54 PM, Joe Emenaker wrote:
>> Okay, I think I understand Subversion enough to be dangerous.
>>
>> I'll need to make a branch to upload my refactored version to. All of
>> the branches seem to be named after version numbers, but my
>> un
On 09/01/2011 07:54 PM, Joe Emenaker wrote:
>
> Okay, I think I understand Subversion enough to be dangerous.
>
> I'll need to make a branch to upload my refactored version to. All of
> the branches seem to be named after version numbers, but my
> understanding is that we can name them anything (li
Okay, I think I understand Subversion enough to be dangerous.
I'll need to make a branch to upload my refactored version to. All of
the branches seem to be named after version numbers, but my
understanding is that we can name them anything (like "my_cool_branch").
Should I name it some step fo
12 matches
Mail list logo
