Jason,
based in that message I did a process ( little based on bitten concepts :-])
according to your idea.
but, I miss something about subversion.
when You say:
your release. And, the developers working on trunk are completely unaffected
as you are working in different directories. Of course, there are more
naming schemes/methods than the one I just mentioned.
I understood, I've a release 1.34.1 working well, and trunk ( 1.35) don't
was affected. How can I do to buid 1.35 with all fixes of 1.34.1? What the
best way to merge both versions? You got?
I think that can be resolved with merge between 1.34.1 and trunk, then I can
buid 1.35 as well.
Thx
On 8/7/07, Jason Winnebeck <[EMAIL PROTECTED]> wrote:
>
>
> If I understand you correctly, you have it almost-but-not-quite. You are
> mentioning working with files, but instead you should work with
> directories/projects. Don't tag just a single file.
>
> You need to manage each "releasable unit" separately. A unit may not
> necessarily correspond to a direct customer deliverable (it could just be a
> JAR/DLL/etc). You mentioned subproject but I don't entirely get your setup
> so for this example I will assume you have a single project/product.
>
> OK, so you work towards 1.34 and you make "trunk" be the code you want for
> 1.34 and you want to release. You tag trunk by copying the entire trunk
> directory into tags/1.34. Now in trunk you start working to 1.35. But, a
> customer finds a bug in 1.34, and you need to support that release and
> make a 1.34.1, what do you do? You copy the entire tags/1.34 into
> branches/1.34.1. Again, the whole directory, not just a file, so you have
> the ENTIRE 1.34.1 codebase in there. You work in the 1.34.1 branch, and
> when you are done and ready to release, you copy brances/1.34.1 to
> tags/1.34.1. So in the tags directory you have 1 directory for each release.
> If you want to see the code for a specific version you just get the code in
> the tags/whatever directory. Because you copied ("tagged") everything, all
> of the code is in there and you can reconstruct entirely any version of your
> release. And, the developers working on trunk are completely unaffected as
> you are working in different directories. Of course, there are more naming
> schemes/methods than the one I just mentioned.
>
> Jason
>
> ________________________________________
> From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of Lucas Stephanou
> Sent: Monday, August 06, 2007 11:01 AM
> To: trac-users@googlegroups.com
> Subject: [Trac] Re: Deployment and Versions
>
> Thx for help Jason.
>
> You got the idea :-)
>
> Let's go ahead with this, thinking in this situation:
> I had a stable version 1.34 (subprojectA) and part of development team is
> working into a new features to version 1.35 ( trunk)
> but there is a bug happening in 1.34 , I'm reallocate one of developers
> to correct this, and he made some
> corrections on project/subprojectA/dir1/file1.py then he tag this file
> with 1.34.1 tag , I generate 1.34.1 and deploy to customer.
>
> After some time I had 1.35 ready to go. But on this time I want to send
> all subprojectA.
> What is correct way to do this. Just svn copy of trunk to tag 1.35??
> and what can I do if in the future I want to regenerate subprojectA
> version 1.34.1 with full tree.
>
> This is my question.
>
> >
>
--
Lucas Stephanou
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
