How to commit changes after checking out working copy from tags ?
I created an initial /trunk /tags /branches directories in new remote svn repository. svn revision is 1.
I imported professional medium size c/c++ project into the /trunk folder. Now, svn revision is 2.
I tagged the imported project.
Now, I need to fix a bug. My plan is to checkout from tags. Fix the bug. Then, how will I commit? Commits aren't allowed on tags.
I imported professional medium size c/c++ project into the /trunk folder. Now, svn revision is 2.
I tagged the imported project.
Now, I need to fix a bug. My plan is to checkout from tags. Fix the bug. Then, how will I commit? Commits aren't allowed on tags.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Working directly in trunk is an incredibly bad idea. You are effectively pushing untested code into the main release branch (at least, that's what truck is supposed to be). I strongly recommend you don't do this. At least, not checking with your companies work-flow policies first.
If your company won't use Git, you can still use it locally. Git allows you to work using a local Git repo and still push to an SVN central source code repository.
https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion
https://git-scm.com/docs/git-svn
If your company won't use Git, you can still use it locally. Git allows you to work using a local Git repo and still push to an SVN central source code repository.
https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion
https://git-scm.com/docs/git-svn
>> you can still use Git locally.
Agree. I did that once while we were using SVN. I sometimes committed twice a day, and when I had a problem, I stepped through a Git GUI and could see the diffs I made on each file, and easily roll back to a working version. Helped a lot when I occasionally needed it. It was also useful in my SVN commit, because I now had a nice listing of the messages I provided during the local Git commits.
Agree. I did that once while we were using SVN. I sometimes committed twice a day, and when I had a problem, I stepped through a Git GUI and could see the diffs I made on each file, and easily roll back to a working version. Helped a lot when I occasionally needed it. It was also useful in my SVN commit, because I now had a nice listing of the messages I provided during the local Git commits.
ASKER
>> You are effectively pushing untested code into the main release branch
I'll test my working copy then commit to trunk
Using Git locally sound great information. But first I need to finish development tasks. I need some ideas of workflows with one developer, svn remote repository, SVN Tortoise Client, development on trunk. Each release will be tagged. Where should I checkout from, tags or trunk ?
I'll test my working copy then commit to trunk
Using Git locally sound great information. But first I need to finish development tasks. I need some ideas of workflows with one developer, svn remote repository, SVN Tortoise Client, development on trunk. Each release will be tagged. Where should I checkout from, tags or trunk ?
So, you don't have a QA process?
I can't really tell you where to checkout from as it all depends on what revision you plan to base your work on. I will say that working directly in trunk is a terrible idea. Surely your company has QA process that forbid this? Normally, you code in a branch. That code gets reviewed and QA tested. Only once it's passed all QA steps would you merge those changes into trunk from your work branch.
At this point I'm not really sure what you're asking me. You say you plan to work in trunk. If that's the case you need to pull the branch tip. You can't work on a tag without branching from that tag. Tags are supposed to be immutable references to a revision. You can't push code against a tag, only a branch tip.
I can't really tell you where to checkout from as it all depends on what revision you plan to base your work on. I will say that working directly in trunk is a terrible idea. Surely your company has QA process that forbid this? Normally, you code in a branch. That code gets reviewed and QA tested. Only once it's passed all QA steps would you merge those changes into trunk from your work branch.
At this point I'm not really sure what you're asking me. You say you plan to work in trunk. If that's the case you need to pull the branch tip. You can't work on a tag without branching from that tag. Tags are supposed to be immutable references to a revision. You can't push code against a tag, only a branch tip.
ASKER
Thank you!
You're welcome. I hope what I explained makes sense. Give git-svn a chance as I'm sure you'll find working with SVN far less painful that way. Good luck.
ASKER
Currently, I'm the only developer on this project. My plan is to develop on the trunk. I don't plan to use branch.
Whether I checkout from trunk latest or tag, I'll get same code but what is my checkout, modify, commit workflow if I checkout
from tags?