Revision storage question

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Angela пишет:
> Hello, I have another question, this time about how revisions are stored.
> I've been reading the website and from http://bazaar-vcs.org/Revision it
> says that revisions don't store an exact copy of every single version.
> Additionally I've read that commits don't succeed unless something in the
> branch has been modified (or you use --unchanged).
> 
> My question/request for clarification is, does that mean that when you
> run a
> commit (say on a whole branch), Bazaar-NG only looks at modified files and
> stores information about that? So unmodified files in each successive
> commit
> don't add up to the total size of the branch?

Yes, exactly. Only changes recorded, so unchanged files don't add
extra space in repository.

> 
> The reason why I'm asking (in case it would help clarify what I'm
> asking) is
> because I'm thinking of making a few directories versioned on my computer,
> and instead of having to run bzr to commit everytime I change something,
> I'm
> thinking of scheduling a task for bzr to try to commit said
> directories/branches on a regular basis (say daily or weekly); since Bazaar
> won't commit if nothing's changed, that works according to plan, but now
> I'm
> curious as to which is "better" in terms of storage space, commit a
> particular FILE (i.e., if I edit something, I commit it afterwards) or if I
> should just let the scheduler take care of things since it will only commit
> the file (in essence) after all.

Bazaar operate in terms of working tree. Usually you have some project,
in which you have many sources/binaries files. This we call "working tree"
or "checkout of branch". Branch also have internal metadata as revisions
that forms actual history of your project.

When you commit some state of project you need to commit several files at once,
otherwise you end up with different set of changes in history and on the disk.
This is bad, because when you need to restore old state of project you need
to do hard work.

So better to commit every time entire state of project at the points where
it's working and don't have critical errors/bugs. Or, if you
need to fix current state of project (even if it break something important)
you usually add correct log message, so you can detect this while browsing
history of your project.

So, committing some states *automatically* on regular basis regardless of current
state of your project(s) is could be wrong idea. Because if you will
commit *automatically* (via cron or windows scheduler) you need to provide some
auto log message, that will be useless in long terms perspective.
And you will fix state of your files in unpredictable state.

If you talk about commit regularly, but manual, it's different.
But anyway, it's better to commit after you finish some step of your work
on project (even if this very small step). Because if you try to commit
many changes at once you have trouble to write good log message
(too many details, some of those you could simply forget, if you
commit once at week).

I hope my explanation clarify things a bit and give you some ideas.

Alexander

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFyEwhzYr338mxwCURAv98AJ4xdoxD+CPRs8UKC/z6Tz7LyZuBjgCfUDEN
jNR9NBsyUO4qoFne/Nl6SEs=
=txb9
-----END PGP SIGNATURE-----