F10 Release Notes PO files

Karsten 'quaid' Wade kwade at redhat.com
Thu Nov 6 07:11:28 UTC 2008

On Thu, Nov 06, 2008 at 11:08:29AM +1000, Noriko Mizumoto wrote:

> Paul, don't worry it does not destroy, but the situation seems not nice.
> This is how I am understanding and had experience when used to work on cvs.
> The translator has been working the file on her machine not commit it to  
> the repository yet, let's say the version 1.0. Beside the author updated  
> this version with some change resulting the version 1.1. Now the  
> translator tried to commit the file worked, but she got error message  
> saying the file is conflict. Because the repository has latest version of 
> 1.1, while she is still trying to commit version 1.0.
> She needs to merge her file of 1.0 and 1.1 locally before commit. If  
> there are 10 translators, this local merge must be done for each language.
> If the author notified translators to commit before update, this merge is 
> not required.

If we can actually use git, we may find these merges a lot easier
because git is a better tool than cvs.

> Now I see strange thing here, and need some help.
> I did 'git pull', so I got latest PO files with 1024 strings intead 1030. 
> I did test commit po_BR.po translated with 1030 strings against latest 
> pt_BR.po with 1024 strings.
> [noriko at noriko po]$ git commit -m 'commit test' pt_BR.po
> Created commit dd92755: commit test
>  1 files changed, 1035 insertions(+), 4134 deletions(-)
> I got no error, but it seems overwritten when I see log.

I just did a 'git pull' and this is what I see:

[kwade at calliope release-notes {master}]$ git log po/pt_BR.po 
commit f3595ce789f269f53a6634688e468f93907717b0
Author: Paul W. Frields <stickster at gmail.com>
Date:   Tue Nov 4 09:35:20 2008 -0500

    Update POT and PO files

Where is your commit?

It is where it belongs, on your machine in your local repository.
Until you do 'git push', you do not merge your local repo to the
remote one.

Because git is a distributed version control system (DVCS), it does
not have a sense of there being a 'master' repository.  Each clone of
a module has the entire commit history up to that point; this is why
you can run 'git log' and get results.  It does not actually check
across the network for this information, as cvs and svn do.

When using git, we make a convetion amongst collaborators as to what
we consider to be the main/canonical repository.  In our case, it is
git.fedoraproject.org/git/docs/release-notes.  But it could just as
easily be the repository on your machine or my laptop.

This, I believe, is part of why git is superior at resolving
differences and doing merges.  In a centralized VCS, two separate
people with checkouts of the repo can go out of sync very easily.
Eeach time you commit to your local clone of a git module, it is a
unique event that can be merged in to the designated master repo.  The
same is true of work done by another person on the same content.

Hope this makes sense ... honestly, I am *still* working on
understanding what git does and why it does it, but I'm mostly happier
with it. :)

For one thing, I can work offline and make granular commits that
remain granular when I 'git push' to the main repo.  It is also faster
and seems to use far fewer computing resources. ;-D

- Karsten
Karsten 'quaid' Wade, Community Gardener
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-trans-list/attachments/20081105/62a1a86d/attachment.sig>

More information about the Fedora-trans-list mailing list