flat assembler
Message board for the users of flat assembler.

Index > Heap > Do you people use version control?

Goto page Previous  1, 2

Which version control software do you use?
Git
21%
 21%  [ 3 ]
Mercurial
7%
 7%  [ 1 ]
CVS
0%
 0%  [ 0 ]
Subversion
28%
 28%  [ 4 ]
Darcs
0%
 0%  [ 0 ]
Perforce
0%
 0%  [ 0 ]
Bazaar
0%
 0%  [ 0 ]
Other
7%
 7%  [ 1 ]
None, I don't use any
35%
 35%  [ 5 ]
Total Votes : 14

Author
Thread Post new topic Reply to topic
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
I like CodePlex, (Wiki,Site,hosting etc.) and they say that Git works best with their site so I choose git. Git is also pretty easier to work with, (with gitGUI), I can't say about others since I've never used them.

_________________
"Those who can make you believe in absurdities can make you commit atrocities" -- Voltaire https://github.com/Benderx2/R3X
XD
Post 18 Nov 2013, 13:42
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
revolution wrote:
... I do like the idea of being able to manually rebuild a corrupted system without having to go into binary file formats and special viewers and/or editors.
Converting An Entire Database To An ASCII Text File

Use the ".dump" command to convert the entire contents of a database into a single ASCII text file. This file can be converted back into a database by piping it back into sqlite3.
Sometime over the next few weeks (time permitting) I'm going to try this out and see just what it produces. If it looks good and I can understand it then I might see about doing an auto-dump before each backup and thus always have a ASCII version for reference in case of any later problems.

ETA: WFT sqlite? I get an error when I try to download anything: "The hyperlinks on the download page only work if you have Javascript enabled in your web browser." So hyperlinks are a new thing and HTML does not support direct links? Suddenly I am not at all keen on something where the devs can't even get a simple webpage link to work.
Post 19 Nov 2013, 03:47
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8896
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
most sites require javascript nowadays to functions.

please proceed with your sqlite adventure, love to hear the results.. =)

i too wish to have important stuff in ASCII just in case,

kinda scare of encrypted drive too, broken means gone forever even you got the password.
Post 19 Nov 2013, 20:49
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
sleepsleep wrote:
most sites require javascript nowadays to functions.
I have very little trouble. It seems to mostly be the "fluff" sites that need JS. More serious sites usually get by just fine without it.

Using JS for a basic link is really poor webpage writing and makes me question the quality and design of sqlite.
Post 19 Nov 2013, 23:08
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
sleepsleep wrote:
please proceed with your sqlite adventure, love to hear the results.. =)

i too wish to have important stuff in ASCII just in case,
Some initial trials show that exporting the sqlite DB as ASCII is a total failure. Completely incomprehensible for a human. Probably something to do the the compressed data format. And I don't want to go into some sort of deep analysis of exactly how to get back the original text.

But instead, using the internal fossil deconstruct command creates ASCII files of the entire repo. So this may be a nice way to have a human readable/reconstructable version. As an additional bonus is that by using 7zip (and a "solid" .7z file) to compress the deconstructed repo produces a single file that is half the size of the original source sqlite repo DB. So if I delete the repo DB and just use the .7z file and the individual deconstructed files I can back everything up easily. Then if I want to update the repo I can use the fossil reconstruct command, do the updates/reverts/commits/whatever and then deconstruct again.

Anyhow I haven't changed anything yet, this is just a little trial I did during a half hour I had free to play with it. There may be something I have completely missed or got wrong, so further tests are needed to see if it will really be a suitable replacement for my current strategy.
Post 20 Nov 2013, 06:18
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
Just now I had a chance to use fossil again for a short time.

I was concerned that when I opened the repo it prompted me to replace my newer/changed files with old copies from the repo. I don't get how that can be a good thing. If I have a newer file the changes could easily be lost by a mistaken keystroke when opening the repo. I found it has the --keep option but I feel that 'keep' should be the default and not the optional setting. I am glad I have my alternate backup working since if I had been solely relying on fossil I might be angry that I had lost all my work and recent changes.

I find the web page UI to be very poorly designed. Almost every link gives an error that JS must be enabled. I can't understand this. The fresh repository also has this problem. It makes it impossible to see the diffs, and whatever else it has, using my browser. This is so very wrong that this alone is probably enough to make me avoid it.
Post 26 Dec 2013, 01:38
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
So I came back to this little test project again (this time remembering to use "--keep"). I made a branch and added some new files and things and committed. So far so good. But then I went back to the "trunk" with the "update" command and fossil deleted the new files placed in the other branch, without even a prompt to ask if it is okay to delete things. Is this really what is considered good practice?

So once again I go back to my backups and recover the lost files.

Perhaps I am just using it wrong? I tried to find an option that tells fossil not to delete my stuff when "update" is used but I could find no such option.

Is there a more robust SCM available?
Post 23 May 2014, 04:13
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
@revolution - you simply need to change your mental model about fossil work-flow. How you use "update"? Probably as "fossil update trunk"? So, you said to fossil that you want your checkout to be updated to trunk branch and that is what you get.

Notice one important thing: When using fossil, all important files are in the repository. The files in the checkout are simply temporary work files, that can be deleted in any time. But once committed, the files can not be lost anymore.

If you want to work on several branches in the same time, simply create several checkout directories and open the same repository in any of them but on another branch. I am using this all the time. For example I have 18 open checkouts of fossil project in this moment.

Once repository opened, it should be not closed anymore until you need to move physically the repository for another place. In this case, commit all changes move repository and open it again.

Read about "merge".
Post 23 May 2014, 05:12
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
I couldn't find any other option to set fossil back to the trunk other than using "fossil update trunk". Is there another way to get back to the trunk branch without "update"?
Post 23 May 2014, 05:49
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
revolution wrote:
I couldn't find any other option to set fossil back to the trunk other than using "fossil update trunk". Is there another way to get back to the trunk branch without "update"?

The natural way is "fossil checkout trunk". And of course, all files in the work (checkout) directory will be replaced by these from "trunk" branch.

If you want to keep and work on the files from several branches in the same time, you simply need to create another directory and open the repository on the other branch.

Later you can merge branches if you want the changes from one branch to be applied to another. (read "fossil help merge")

And again - never use "fossil close" on any open checkout, unless you want to remove the whole directory or to move the repository database.

Let see how it will look. Imagine you have an repository with two branches: "trunk" and "experimental":
Code:
mkdir trunk
cd trunk
fossil open %path%/MyProj.fossil trunk
cd ..
mkdir experimental
cd experimental
fossil open %path%/MyProj.fossil experimental
.... here you make any changes to the experimental branch... adding new files, editing, deleting, etc.
fossil commit 
.... check, compile, test - yes it is great new feature, but has bugs...
.... debug, edit, compile test - yes it works now.
fossil commit
cd ../trunk
fossil merge experimental 
fossil commit   ; the merge happens in the checkout, so you need to commit it (if everything is fine).
... now you have new version with the fine new features applied to the trunk.    

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 23 May 2014, 07:25
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
I see. Thanks for the explanation. My work flow does not happen in that way. And fossil is clearly getting in my way when it tries to impose this work flow.

I would be happy to use fossil for diff exploration and archiving and whatnot. But I am not prepared to trust it with being the sole manager for all the source files. If I have a file on disk I expect it to be unmolested by default and only overridden or deleted with appropriate "are you sure?" prompts. I treat my disk files as the definitive versions and any other tools that may keep a copy of them are considered only good for backups and/or archiving.
Post 23 May 2014, 08:03
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
revolution wrote:
But I am not prepared to trust it with being the sole manager for all the source files.


Well, the "trust" is really irrational thing... Actually because of the ACID database, fossil can store the files in more robust manner than the file system. Even power loss during the commit will not lead to database corruption, only the current commit will be rolled back.

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 23 May 2014, 09:49
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
The obvious flaw there is that the archive is stored within the file system. I don't see how it is possible to more robust than the base it is used within.

A file on disk is only as secure as the file system storing it. The repository is stored as a file on the disk. So ...
Post 23 May 2014, 10:02
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
revolution wrote:
A file on disk is only as secure as the file system storing it. The repository is stored as a file on the disk. So ...


It is not so simple. There are software ways to provide additional robustness to the database files. For example, if you rewrite a text file continuously and switch the power down, the file will probably end partially written or even broken at all.

In the same conditions, writing continuously the same file to a SQLite database, you will get totally not broken database and fully written text.

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 23 May 2014, 10:10
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
Oh, for a single file, yes you are correct. But I have an archiving system that stores old versions without touching the original. I might lose one or more files due to some disk problem but a repo file will have that same level of disaster exposure. And naturally that is what backups are for, to provide redundancy in case of any disk related difficulties. But I still have trouble coping with fossil deleting files at its whim without any prompts. At least they could give a switch option to disable warnings if I find them annoying.

So just now I did a bit more testing with my forked project. Since I am now "checked-in" on the trunk and I edit one of the branch files then fossil doesn't see the edits and is unaware of any changes. And I realise I am using outside of its intended usage so this is the cause of the blindness. But the repo does have the file listed as existing (in a different branch) but it won't check it for updates. And if I switch branches ("fossil update mybranch") it will overwrite those edits on disk and I lose my work (again).
Post 23 May 2014, 10:33
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
BTW, you always can use "fossil undo" if something goes wrong.

To think about the version control system as an archive system is wrong. The version control system is not an archiving system. It have different logic and different behavior. The only place, where the file is safe is when committed in the repository.
Post 23 May 2014, 12:09
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
JohnFound wrote:
To think about the version control system as an archive system is wrong. The version control system is not an archiving system. It have different logic and different behavior.
Yeah. This has been my problem all along. Thanks for making me understand that. Perhaps I will try again with a different project. Now with this new thinking and mindset perhaps I can get something of use out of it.
Post 23 May 2014, 12:13
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
I got this message from fossil when trying to commit a change:
Quote:
New_Version: d073030ea498f1d8058807a61f044e86a651eab3
SQLITE_CORRUPT: database corruption at line 56988 of [7757fc7232]
SQLITE_CORRUPT: statement aborts at 8: [SELECT content FROM blob WHERE rid=:rid AND size>=0]
fossil: SQL error: database disk image is malformed

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
Using rebuild didn't help. Fortunately I keep backups of both my source files and the repository I was testing with so I was able to go back to a working repository file and redo the checkins.

Keeping all one's eggs in one basket is perhaps something one should consider more carefully.
Post 17 Feb 2015, 12:07
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:  
Goto page Previous  1, 2

< 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.

Powered by rwasa.