One Star

SVN Branches and tags

Hello, Sorry if this topic has been dealt already but i could nt find information i am looking for.
When should i use a branch vs a tag? I have created some jobs in trunk and when i created a branch from TAC it automatically copied all the existing jobs in trunk to the new branch is that how it works? i would only want to move jobs to this branch if the job is funtioninig so how do i control this? and is there a way to restrict access to branches and tags? is it better to create seperate projects for each of the env such as dev/test/qa/prod rather than branches or tags ?

Re: SVN Branches and tags

Have you read some related documents on talend help center TalendHelpCenter:Managing Jobs on different SVN branches and tags and TalendHelpCenter:Managing SVN branches and tags for a project
Best regards
Don't forget to give kudos when a reply is helpful and click Accept the solution when you think you're good with it.

Re: SVN Branches and tags

I don't know what JoAnu will say, but I think this is a good question and that the HelpCenter doesn't address any of the questions.
JoAnu, I also have questions how best to use SVN. I don't think any documentation exists from Talend or anyone else, about typical ways to use SVN, best practices, etc. with Enterprise DI.
If by any chance you have access to, they have a decent video intro to SVN.
Couple points (and any corrections are welcome):
When you create a branch, it doesn't consume a lot of space, if that relates to your concern.
It's not typical to move working things into a branch for separate management, if you're thinking like a branch called "production". Usually Trunk is the main working code set and branches are for trying new features or implementing fixes, and they merge back to trunk or get discontinued. SVN doesn't force you to follow that paradigm but you're swimming against the tide if you don't.
Is there a way to restrict access? I don't know.
is it better to create seperate projects for each of the env such as dev/test/qa/prod rather than branches or tags ?

I think you wouldn't do either - the context groups is the "normal" way to control what environment a job runs on - what servers/folders/credentials are used. You don't want a different copy of the job for different environments. Context groups aren't necessarily the final answer. Another approach: