DEV Community: Melisha Trout

How to synchronise between SVN and Git.

Melisha Trout — Sun, 29 Jan 2023 01:55:47 +0000

Photo by Cas Holmes on Unsplash

In my last post, I mentioned how one could migrate from SVN to Git. In this post, I will explain how to synchronise any changes between Git and Subversion (SVN) that may have occurred during the migration process.

There will always be that one person in your team that did not get the memo and committed some changes to SVN whilst you were in the middle of the migration. Don’t stress yourself out about it; there is a fix, and I will show you how.

The process is pretty straightforward and will include the following steps:

1) Creating a sync branch

2) Merge changes from SVN to Git

3) Optional: Merge changes from Git to SVN (if needed)

Please Note according to the git svn documentation there is a command called git svn rebase. The _git svn rebase_command retrieves any changes made in the SVN repository and applies the changes to the current work within Git. This command is similar to svn update or git pull however , whenever I have tried to use this command in the past it would timeout on me. That is why I used the following process to sync the changes successfully. However, if this command works for you, please use it, yet if it does not, then continue reading.

Create a sync branch

We will need to create a new branch within git, which we will call svn_sync. This will allow us to pull any changes made from the main branch after the migration. Also, note that this branch will only be used to set up a connection to SVN, it will not be used for any development.

git branch --no-track svn_sync

Once the branch is created, checkout the branch and initialise the repository to the SVN repo. Once initialised, fetch the SVN repo making sure that the authors file that was used in the original migration is up-to-date.

git svn init -s https://mycompany.com/path/to/svn/repo
git svn fetch --authors-file=../authors.txt

If needed you can set the author’s file location so that you don’t have to type it out again.

git config svn-remote.svn.authorsfile ~/authors.txt

Optional : If you had set up git LFS during the migration, you will need to perform the same setup in the new branch. If you need to remember how this is done, checkout the ‘Convert any large files to LFS objects’ section in my original post:

How to migrate SVN to Git

Merge changes from SVN to Git

Checkout the master branch and then merge the svn_sync into master.

git checkout master
git merge svn_sync

Once everything is merged and there are no conflicts, you can now push the merge changes to the remote repository

git push origin master

Optional: Merge changes from Git to SVN (if needed)

If you run into an issue whereby you would need to merge changes from git back to SVN then have fear! It’s just a simple process and I will help you through it.

First checkout the current release branch or the most up-to-date branch in git(this can be the master branch) and pull in the changes

git checkout master
git pull

Then you will need to checkout the svn_sync branch and pull the latest changes:

git checkout svn_sync
git svn fetch
git svn rebase

Now you will need to merge the changes from the release or master branch into the svn_sync branch:

git merge --no-ff master

If there are any conflicts, you will need to resolve them at this stage. Once they are resolved you will need to commit the changes locally and then commit the changes to SVN:

git commit -a
git svn commit

And there you have it, you have successfully synced between SVN and Git. I hope that this post was helpful. If you want to read more of my career advice and tech takes, consider following me as well as signing up for my newsletter so that you will never miss my post.

How to know when it is the right time to ask for help?

Melisha Trout — Thu, 08 Dec 2022 14:49:10 +0000

As a software engineer

Photo by Tim Mossholder on Unsplash

As a software engineer, it is important to be able to work independently and solve complex problems on your own. However, there may be times when you need help, either because you are stuck on a difficult problem, or because you want to learn a new skill or technology. In these situations, it can be difficult to know when it is the right time to ask for help.

Here are some signs that it may be time to ask for help as a software engineer:

You have been stuck on a problem for a long time. If you have been working on a problem for an extended period of time and you are unable to find a solution, it may be time to ask for help. It is important to be persistent and try to solve problems on your own, but if you are stuck and unable to make progress, asking for help can save you time and frustration.
You are unsure of the best approach to a problem. Even experienced software engineers may not always know the best way to solve a particular problem. If you are unsure of the best approach to take, asking for help can give you valuable insights and perspectives that can help you find a solution.
You want to learn a new skill or technology. As a software engineer, you will constantly be learning new skills and technologies. If you want to learn a new skill or technology, asking for help can be a great way to get started. You can ask other members of your team or your colleagues for advice and guidance, or you can attend workshops and conferences to learn from experts in your field.
You are working on a complex project. Software engineering projects can be complex and involve many different components. If you are working on a complex project, asking for help can be a valuable way to manage the project and make sure that it is completed on time and to the required quality standards. You can ask for help with specific tasks or with the overall project management, and you can work with other members of your team to divide the work and ensure that the project is completed successfully.
You are experiencing stress or burnout. Software engineering can be a demanding and stressful field, and it is important to take care of your mental health and well-being. If you are experiencing stress or burnout, asking for help can be a valuable way to manage your workload and reduce your stress levels. You can talk to your manager or your colleagues about your workload and your stress levels, and you can work together to find solutions that can help you manage your workload and reduce your stress.

Overall, knowing when to ask for help as a software engineer is an important skill. By being aware of the signs that indicate that it may be time to ask for help, you can ensure that you are able to solve complex problems, learn new skills and technologies, and manage your workload effectively. Asking for help can be a valuable way to improve your skills and advance your career as a software engineer.

How to become an effective software engineer

Melisha Trout — Thu, 08 Dec 2022 11:28:44 +0000

Photo by Kelly Sikkema on Unsplash

Over the last fours year of being a software engineer, I realise that being an effective software engineer requires a combination of technical skills and soft skills. In this post, we will explore some of the key qualities and characteristics that make a software engineer successful and provide some tips and advice on how to develop and improve these skills.

Be curious and always be learning. The field of software engineering is constantly evolving, with new technologies and frameworks being developed all the time. In order to stay up-to-date and be an effective software engineer, you need to be curious and always be learning. This means reading blogs, attending conferences and workshops, and staying up to date with the latest developments in your field.
Write clean, well-organized code. One of the most important skills for a software engineer is the ability to write clean, well-organized code. This means using good coding practices, such as using descriptive variable names and commenting on your code, to make it easy for other developers to understand and maintain. It also means using the right design patterns and architecture to make your code scalable, maintainable, and easy to test.
Be a good communicator. As a software engineer, you will often be working in a team, and you will need to be able to communicate effectively with other members of your team. This means being able to clearly explain your ideas and solutions, and being able to listen and understand the perspectives of others. It also means being able to communicate with non-technical stakeholders, such as business managers and customers, and explain complex technical concepts in a way that is easy for them to understand.
Be organised and detail-oriented. Software engineering projects can be complex and involve many different components. In order to be effective, you need to be organised and detail-oriented, and be able to keep track of all the different parts of your project. This means using project management tools, such as Trello or Jira, to manage your tasks and deadlines, and being able to prioritise your work and make sure that the most important tasks are completed on time.
Be able to work under pressure. Software engineering projects can be fast-paced and demanding, and you may need to work under tight deadlines or handle multiple tasks at once. In order to be effective, you need to be able to handle pressure and stay calm in stressful situations. This means being able to work efficiently and prioritise your tasks, and being able to communicate clearly and effectively with your team members when things get hectic.
Be willing to take on new challenges. As a software engineer, you will be constantly learning and facing new challenges. In order to be effective, you need to be willing to take on new challenges and step outside of your comfort zone. This means being open to trying new technologies and learning new skills and being willing to take on difficult tasks and push yourself to grow and improve as a software engineer.

Overall, being an effective software engineer requires a combination of technical skills and soft skills. By being curious and always learning, writing clean code, being a good communicator, being organised and detail-oriented, being able to work under pressure, and being willing to take on new challenges, you can develop the skills and qualities you need to be successful in this rewarding and dynamic field.

What is the main difference between Git and SVN?

Melisha Trout — Thu, 08 Dec 2022 11:15:43 +0000

Photo by Max Duzij on Unsplash

Git and SVN are both version control systems, which are tools that help developers manage changes to the source code of their software projects. Both Git and SVN allow developers to track changes to their code, revert to previous versions, and collaborate with other members of their team. However, there are some significant differences between the two systems that make Git a better choice in many cases.

One of the main differences between Git and SVN is the way they handle data. Git is a distributed version control system, which means that every developer who works on a project has a complete copy of the entire project history on their own computer. This allows developers to work independently and commit changes to their local copy of the project, without needing to be connected to a central server. This makes Git ideal for working on projects with a distributed team, or for working offline.

SVN, on the other hand, is a centralized version control system. This means that there is a central server that holds the latest version of the project, and all developers who work on the project need to be connected to the server in order to commit their changes. This can make collaboration more difficult, especially for teams that are geographically dispersed, or for teams that need to work offline.

Another key difference between Git and SVN is the way they handle branching and merging. Branching allows developers to create new versions of their code without affecting the project’s main branch. This is useful for working on new features or bug fixes, without disrupting the work of other team members. Git makes it easy to create and manage branches and has powerful merging tools that allow developers to easily combine changes from multiple branches.

SVN, on the other hand, has a more limited approach to branching and merging. It allows developers to create branches, but it does not provide the same level of support for managing and merging them. This can make it more difficult for developers to work on multiple versions of their code at the same time, and it can lead to conflicts and errors when merging changes from different branches.

Another key advantage of Git over SVN is the way it handles conflicts. When multiple developers are working on the same project, there is always a possibility that they will make changes that conflict with each other. Git has powerful conflict resolution tools that allow developers to easily resolve conflicts and merge changes from multiple branches. SVN, on the other hand, does not provide the same level of support for resolving conflicts, which can make it more difficult for teams to collaborate and merge their changes.

Overall, Git is a more powerful and flexible version control system than SVN. It allows developers to work independently and offline, it provides better support for branching and merging, and it has more advanced conflict resolution tools. For these reasons, many developers prefer to use Git for their projects, and it has become the most popular version control system in the world.

How to migrate SVN to Git

Melisha Trout — Thu, 25 Aug 2022 00:38:35 +0000

Photo by Markus Winkler on Unsplash

I was recently working on a migration project which include migrating our codebase from SVN to GitHub. After a few trials and errors and plenty of hours searching the web for best practices, I finally managed to develop a system that did not cause any tears during the process and I thought it would be nice to share it with you.

I have broken down this migration process into 4 simple steps:

Prepare your environment
Convert your SVN repository to a local git repository
Convert any large files to lfs objects (if needed)
Push the new git repository to GitHub

Prepare your environment

On your local machine create a GitMigration folder which will host your new git repo: mkdir -p ~/GitMigration

In another command line update the SVN repo to make sure that you have the latest revisions. It would be also wise to inform your team that you are starting the migration and no more commits will be allowed to be pushed to SVN until the migration process is complete.

Once that is done you will need to create an authors.txt file. This will map the SVN usernames to the desired Git usernames in the following format:

jdoe = John Doe <john.doe@gmail.com>
esmith = Emma Smith <emma.smith@gmail.com>

If you don’t want to find all the authors in the SVN manually you can pull the data from the SVN repository using the following command, just make sure that the final format follows the same structure as above:

svn log -q | awk -F '|' '/^r/ {gsub(/ /, "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors.txt

Convert your SVN repository to a local git repository

If you want to only migrate commits from a certain time period, you will need to locate the revision number in the SVN repo. To do this excuse the following command in the svn repo folder:

svn log -r {YYYY-DD-MM}:HEAD --limit 1

Within the GitMigration folder execute the following command:

git svn clone <svn-repo>/<project> <git-repo-name> --authors-file=authors.txt -r <revision-number>:HEAD

Where ＜svn-repo＞ is the URI of the SVN repository that you want to migrate, <project＞ is the name of the project that you want to import, and is the revision number that you want to migrate from (if needed). The ＜git-repo-name＞ is the directory name of the new Git repository. This process might take a while, depending on the size of the SVN commits.

Now comes the clean-up, moving the tags and any remote refs to local branches. To move the tags to proper Git tags execute the following within the git repo directory:

for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags\//} $t && git branch -D -r $t; done

Next, move any references under refs/remote and turn them to local branches

for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git branch $b refs/remotes/$b && git branch -D -r $b; done;

for p in $(git for-each-ref --format='%(refname:short)' | grep @); do git branch -D $p; done;

Convert any large files to lfs objects

GitHub has a file limit of 100MB, anything over that size will be refused to be pushed into GitHub. This is where Git Large File Storage (LFS) comes in. Git LFS replaces any large files with text pointers inside Git while storing the file contents on a remote server. There are many benefits to using LFS such as

Large file versioning
More repository space
Faster cloning and fetching
Same Git workflow
Same access controls and permissions

To find out how many files that are above the 100MB limit run the following command:

git lfs migrate info --everything --above=99MB

this will print out information about the different file types in your repo that are above the 99MB mark (as shown below).

To convert the files to LFS file objects run the following command:

git lfs migrate import --everything --above=99MB

This will rewrite the history of the git repo that contained any files that were above 99MB and convert them to LSF objects.

Push the new git repository to GitHub

The final step is to add the remote git server and push the changes.

git remote add origin git@my-git-server:myrepository.git

git push origin --all;

git push origin --tags;

And that’s it! Congratulations, you have migrated your SVN repo into Git. The next step is to inform your team that the migration is complete and provide them access to the new remote git server.

How to know when it is time to move on from your workplace

Melisha Trout — Mon, 22 Aug 2022 00:32:54 +0000

from a Software Engineer perspective

Photo by Chase Clark on Unsplash

Time is a friend when we use it for good by acting, not for evil by letting it slip away.

No matter how much you love your job, there always comes a time when you have to move on. You may get promoted and given a bigger role or responsibility, or the company may be downsizing. Whatever the reason for moving on, making that decision can be hard. It’s never easy to leave your comfort zone. But with these tips that will help you know when it is time to move on from your workplace, this will be easier than you think.

The work no longer interests you

This is very important. The work that you do should stimulate you, make you look forward to going to work and make you feel as though you are establishing something. If you feel dread every morning, have zero motivation to do your tasks, the projects that you are currently working on no longer interest you or you are completely switched off then maybe it is time to dust off your C.V and start looking elsewhere.

There is no room for progression

This is the number one reason I have accumulated many job roles in the past fourteen years. What is the point of staying if there is no room for progression? Some might say that they are too comfortable and cannot be bothered to go through the interview process again. I say stuff that! The main reason why people work is to make money so that they can buy food, pay bills and sometimes enjoy the finer things in life. We work to live, not live to work.

If you have been at a company for many years (2/3 years) and are still in the position as you were when you first join then maybe you could do the following:

Book a meeting with your direct report
Explain to them that you are interested in moving on to the next level and find out what it is that you need to do to get there and make a plan!
Execute, execute, execute! Make sure you left no stone unturned for them to give you an excuse for not giving you that pay rise or a promotion.
Every time you achieve something, albeit if it was small or not, make a note of it and the impact it made on the team or for the company.
Book another meeting 6 months after your first performance review, highlighting all achievements you have made so far and why you are ready for a promotion.

If you follow the steps above and still get no outcome then get the hell out! There is no point in staying, the company doesn’t value you enough to keep you on, which leads to the next point…

You haven’t had a significant pay increase in many years

Let’s face it, the number one reason why we go to work is to be paid. To earn money to pay our bills, put food on the table and a roof over our heads and maybe enjoy some finer things in life. With the current financial situation, national insurance increase, energy bill crisis, food prices going up and the cost of living going up, it is more important than before that you are getting paid your worth. Currently, the job market for Software Engineers is booming and the pay reflects it. If you are not sure that you are getting paid the industry average, take a look at places like Glassdoor

Your workplace environment has become too hostile to continue working

Many studies have proven that workplace hostility is significantly related to higher turnover. Furthermore, if there is no employee support the number of employee attrition increases significantly. Continuing to work in a hostile workplace will not only affect your performance but also your mental health. That is why it is important when looking for a new job that the compensation reflects your skill set and that the team and the company’s culture fits your needs.

There are many other reasons why people decide to leave their jobs; the reasons above are just a few. Whatever the reason may be, it is important to know that you are a human being, work should not be your identity nor should you feel as though you owe your workplace anything. For every employer who is looking for every employee and every job that fits perfectly, many more positions remain available and untouched. So as a potential candidate, always keep your options open.

When is the right time to move on from your workplace?

Melisha Trout — Mon, 22 Aug 2022 00:32:54 +0000

from a Software Engineer perspective

Photo by Chase Clark on Unsplash

Time is a friend when we use it for good by acting, not for evil by letting it slip away.

The work no longer interests you

This is very important. The work you do should stimulate you, make you look forward to going to work and make you feel like you are establishing something. If you feel dread every morning, have zero motivation to do your tasks, the projects that you are currently working on no longer interest you or you are completely switched off then maybe it is time to dust off your C.V and start looking elsewhere.

There is no room for progression

What is the point of staying in your company if there is no room for progression? Some might say that they are too comfortable and cannot be bothered to go through the interview process again. I say stuff that! The main reason why people work is to make money so that they can buy food, pay bills and sometimes enjoy the finer things in life. We work to live, not live to work.

If you have been at a company for many years and are still in the position as you were when you first join then maybe you could do the following:

Book a meeting with your direct report
Explain to them that you are interested in moving on to the next level and find out what it is that you need to do to get there and make a plan!
Execute, execute, execute! Make sure you left no stone unturned for them to give you an excuse for not giving you that pay rise or a promotion.
Every time you achieve something, albeit if it was small or not, make a note of it and the impact it made on the team or for the company.
Book another meeting 6 months after your first performance review, highlighting all achievements you have made and why you are ready for a promotion.

If you follow the steps above and still get no outcome then get the hell out! There is no point in staying, the company doesn’t value you enough to keep you on, which leads to the next point…

You haven’t had a significant pay increase in many years

Your workplace environment has become too hostile to continue working

Teacher to Backend Software Engineer

Melisha Trout — Wed, 16 Feb 2022 13:40:30 +0000

How I change my career in my late twenties.

I would like to think that my past decisions have paved the way for me to get where I am now. Hopefully, by sharing my experience, I will be able to convince others that it is never too late to pursue your dreams. This applies regardless of your age or background.The path to where I am now was not traditional, nor was it a result of learning to code since I was 6 years old.

In 2013, I graduated from Hull University with a BSc in Psychology. I wanted to become a Clinical Psychologist but needed work experience first. Within a few months of graduating, I secured a position as a trainee special education teacher. Eventually, though, I realized that wasn’t the most appropriate path for me. Hence, I quit.

In those days, companies were reluctant to hire anyone who had worked within the education system. This was due to concerns that the candidate would not be able to adjust to the changed setting. Although I had this limitation, I managed to get a job as a Website Assistant for a company called Loved Shopping Ltd; it was at this company that the desire for me to become an engineer began to grow.

The learning opportunity that comes from working with peers is the one thing I’ve missed the most since becoming a remote worker. Listening in on what other people are working on, the issues they are facing, and how they plan to solve them. This was what I used to do at Love Shopping Ltd which consequently sparked my interest in software development. The lead engineer was talking with an executive about statistical significance one day. It turns out they were doing an A/B test on the homepage and they were looking at the current result.

This sparked my interest in digital marketing and so I took a course in Digital Marketing and started looking for a new job within this field. That’s when I managed to land a job position as a Digital Content Assistant at The Camping and Caravanning Club. From here I started to work alongside the engineering team, learning about front-end development. There was a situation at work where unfortunately they were not planning to replace the engineering team, instead they were looking to outsource the majority of the work leaving only one front-end engineer left to guide and support the newly formed external team.

This also gave me the opportunity to gain some valuable experience through collaborating closely with the engineering team, learning about front-end development and the different processes. I worked closely with the team for three months before I had to move back to my old team. I continued to work for the CRO team for another 3 months, then I quit my job. The experience that I gained during my short skint with the development team made me question my future. Did I want to continue working as a CRO or have I changed my mind again and wanted something different? I bet you can guess what happen next. In August 2017 I handed in my noticed and enrolled back to University to study a MSc in Computer Science.

Fast forward to today, I now work as a Software Engineer I at a company called Optimizely for nearly 4 years. I first started out as an Integration Engineer, responsible for onboarding and troubleshooting clients onto Optimizely’s Personalization platform. I now work in the Backend team, building data intensive applications for the platform.

You may notice one common theme throughout my journey. Once I realise that something wasn’t right for me I quit. I didn’t lingered on to see “how things turned out”; I just left. For some people, I may come across as reckless and irresponsible and I’ve been told by many people that they would prefer to hire someone who has been in a position for more than 3 years. However, times are changing and you need to do what is right for you and nobody else.

What’s next?

To be honest, I don’t know. I have stopped making long term goals as they never turn out right. Instead I have decided to try and live in the moment and focus on smaller goals like reading 10 pages per day or focus on my personal projects for 30 mins, 3 times a week. One thing I have learnt over the years is that life is a marathon, not a sprint so you might as well enjoy it.
FYI if you or you know someone that is looking for a Software Engineering role, my company Optimizely, has plenty open positions available world-wide. Click here to find out more.