flat assembler
Message board for the users of flat assembler.

Index > Heap > version management & team work

Thread Post new topic Reply to topic

Joined: 20 Feb 2006
Posts: 4240
Location: 2018
even alone, manage the differents (consecutive/fork) versions of any project is pretty hard and confusing.

take as an example, the case you work alone on a "huge" project, say it is composed by many files.
you will have the original on a machine, say M01.
and you copy it to an amovible drive, say D01.
you put D01 in the machine M02, and modify the sources directlly in D01.
you copy the content in M02, and continue to work on M02.
you put D01 in the machine M03, and so on...
then, you continue to work on the code on M01, while you work also on the code on M02, D01, M03, D02, etc...

what is anoying then, whatever version management tool you use, is the update and commit phase.
you will always have to manage conflicts.

then, what to do?

personnaly, for my own projects, i prefer let my brain use a detailled whatsnew file, and compare just the whatsnew, then, merge manually the changes (copy/paste), and update the whatsnew.

my own conclusion is that a project with many working copies everywhere is a cure to update, and using a sort of "automated" tool to do the job is like using a sextoy to fecundate our wives.

better is to use good communication of what was done, and update the changes manually.
remember that the long task in coding is not to copy paste code, but to write and test it line by line. ones the code is ok, copy paste is a neggligible task.

and ones you have a pretty good and complete version, you can commit to svn/git/etc... to broadcast to the community.

before, use communication, send by mail, or anything else, to the more responsible coder (like linus does when he compiles and validate a linux kernel), this person will then commit to the version management tool.

but as long as the IT evolve, the tendency is to give the job to pretty uncompetent people that will commit not working code...( like me) and be annoyed by the old (2 month ago) crappy code commited. then, remember to backup your work, outside the version manager, somewhere on some drives. and manage them by hand.

and don't forget to backup, and multiply the copies on many different storages.

Post 11 Sep 2012, 19:41
View user's profile Send private message Visit poster's website Reply with quote

Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
If I work on different drives - I use a simple DIFF. tool to compare directores - just to see the changes I made or forgot to make.
It is not a merging tool, just a tool for seeing the differences.
But for a team of ASM coders - yeah, that would be not enough, I imagine.
Post 11 Sep 2012, 21:06
View user's profile Send private message Send e-mail Reply with quote

Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
I like distributed version control systems. It is really better than the centralized systems. At least you have full backup on every machine cloned the repository.

The VCS can save you a mass of time. IMHO, every programmer must learn at least one good VCS and use it all the time. Because this way he will be able to create his projects faster and better.

And IMO, by the ideology reasons, for assembly programmer, the best choice is "fossil" DVCS, because it is very small, light and minimalistic. Wink
If someone think VCS is big and clumsy environment with clients, servers, setup and administration - he must try fossil.
Post 12 Sep 2012, 04:44
View user's profile Send private message Visit poster's website ICQ Number Reply with quote

Joined: 08 Jan 2004
Posts: 179
Location: Israel
JohnFound wrote:
I like distributed version control systems. It is really better than the centralized systems....

And IMO, by the ideology reasons, for assembly programmer, the best choice is "fossil" DVCS, because it is very small, light and minimalistic. Wink

I second JohnFound's endorsement of "fossil". It's very robust, small and capable -- I use it for all my projects.
Post 12 Sep 2012, 07:18
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger Reply with quote

Joined: 08 Nov 2008
Posts: 165
My method is to assign a special plaintext file as the central info resource

Every-single-time I did anything to the source - deletion, addition, change - I document what I did on which file(s), and when, and on which drive / machine / location

And that plaintext file I keep it on my thumbdrive, which I take with me everywhere I go

That way I have a central resource to fall back on

But of course, I backup everything
Post 12 Sep 2012, 10:02
View user's profile Send private message Reply with quote

Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
edfed, for responsible VCS, you don't push non-working code to the main repository. For non-distributed systems like subversion, this simply means you don't commit non-working code. (Of course there's exceptions when doing initial project setup/scaffolding, or working on larger feature branches, but at the very least you don't push stuff that doesn't build, or breaks functionality for people not working on the same feature as you).

For decentralized VCS, you generally make feature branches for every little feature, since they're so inexpensive and don't affect anybody else. You do multiple commits (possibly even non-working code!) to your local repository, with commit message detailing what the changes are (and there goes the need for maintaining a stupid separate .txt file with changes). You now have the ability to do a lot of code experimentation without having to revert to older versions from clumsy backups, you have superior diffing capabilities, et cetera. And if you need to work on a different feature before completing the one you're currently working on (critical bugfix necessary, management reassigning priorities, ...) it's a very easy thing to do.

Once a feature is complete, you squash all your local feature-branch commits into a single commit back to the mainline (thus not polluting the global history with your, possibly many and experimenting, local commits), and then you either push changes to the central project repository (the "we've just moved to DVCS and are still learning" or "we have extremely competent developers" approach), or you issue a pull request to the responsible project maintainer, who will then evaluate your changes and hopefully merge them into the central repo.

Oh, and because of it's decentralized nature, it's possible for multiple developers to work on the same feature, without going through the central repository, and without resorting to stupid methods like email, instant-messaging file transfer, and the like.

It's a much, much better way to work than any of the archaic manual methods that have been proposed so far in this thread... but it's not a magic silver bullet, and you still need to communicate with your fellow developers.

(Oh, and while proper (D)VCS is absolutely necessary in a team situation, I wouldn't do without it on anything beyond toy projects even when doing single-developer work. It's just too valuable having a decent searchable and diffable history of your source code.)
Post 12 Sep 2012, 11:02
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum

Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.