On 16 Jun 2013, at 11:00, Ryan Ollos <[email protected]> wrote:
> On Sat, Jun 15, 2013 at 4:28 PM, Antonia Horincar < > [email protected]> wrote: > >> Hi, >> >> Thanks for your reply. I am going to take a closer look at the >> existing components to see how are they being processed in their >> current implementation. I might need to ask some more questions >> regarding this aspect, but I'll get back to you after I have a better >> look at them. >> >> Also, it's the first time I'm using Subversion as a version control >> system and I'm not sure how are we going to be able to commit things. >> I have cloned the repo, but I'm not sure of whether we are allowed to >> simply commit things, without 'asking' for permission (like pull >> requests in Git) or not. And if not, what steps should we follow in >> order to be able to commit? >> I'm a little bit scared at the thought of 'breaking' things, so if you >> have some useful tips on SVN, that would be really appreciated (I'm >> not talking about obvious steps, but maybe some of you have >> encountered some special situations, and have some advise on the good >> practice of SVN). Some more on good practice: You should always commit early and often. If you're unsure if something should be committed yet, err on the side of committing it too early. Talk about what you commit. Bring it up on this dev list. If you feel that you've already talked about it too much and people haven't been replying lately: keep bringing it up. Try to make it a habit. If people don't reply, it generally means that they agree with your approach, aren't concerned by your decisions and have nothing else to add. That's good. - Joe > > I can mention a few things that I see people in SVN stumble on. We have the > good fortune of having two long-time SVN developers on the project in our > mentors Brane and Greg, so I'm sure they'll jump in and correct me if any > of this is incorrect, or in any way less than accurate. > > - You'll be working on a branch, and it's a good idea to regularly (say, > once per week, or more) merge from the trunk and keep you branch synced up > with the trunk. > - Always merge into a clean working copy, and don't make any modifications > to the working copy before committing the results of a merge (probably > obvious and applicable to Git as well, though you may have worked primarily > with rebasing). > - Always merge from the root of your working tree. That is, merge /trunk > to /branches/antonia, and don't try to merge /trunk/somedir to > /branches/antonia/somedir. SVN tracks the merged changesets through the > svn:mergeinfo metadata which is attached to a directory, so performing a > merge on a subdirectory and littering this metadata throughout your tree > can cause headaches. I don't imagine that you'd do this because the size of > our working copy is fairly small, but you might be surprised how often I > see people do this on large repositories. > - This probably won't come up for your project, but SVN can cause some > headaches when files that also exist on another branch are moved. You are > fine to move around files that you add to your branch, and that don't > already exist on the trunk or another branch. > > If you are comfortable with Git, you may want to use Git as a client and > use the Git-SVN connector to push changes to the repository. I've found the > Git client to be useful in this case for allowing me to stage and > reorganize my changes locally, which ultimately results in cleaner > changesets pushed to SVN. I recently read someone describe it as a "patch > manager on steroids", and it works well for that in my experience. Just > make sure to push your work regularly so you can get feedback on it. > > Welcome aboard! > > - Ryan
