Revision control
-
Hi,
Just noticed that there's no file id anymore in any of files so how are you guys managing file rev controls. Well, I know nothing about git but it seems things happening(missing $Id$ in the file) since git is introduced. For a simple example below excerpt from /etc/rc.
it used to be like this;
$Id: rc,v 1.192.2.146 2008/12/23 19:29:37 sullrich Exp $
now it's empty and not able to see the file is/was modified or not;
$Id$
Question. How could I know that the files are updated between snaps.
cheers,
-
Still working out the snags with git. I'm not sure what you ask is actually possible. What we'll probably end up doing is putting the build number in the version file.
–Bill
-
we'll probably end up doing is putting the build number in the version file
I like this idea.
-
Thanks for your comment, Bill.
I really appreciate that one of core developer slightly paid attention to my kinda silly asking. I can survive of course if there's anything that describes revs, but really you guys have no issues without rev id? Is there any un-foreseen situations that whole bunch of revs are somehow messed up? How could you know who owns/modifies file? I am a bit old timer, co/ci rcs guy, just started learning the nature of git, can't reach up-to-date technology yet.
Please consider to provide a simple txt such as change log kinda style for each snap.
-
Thanks for your comment, Bill.
I really appreciate that one of core developer slightly paid attention to my kinda silly asking. I can survive of course if there's anything that describes revs, but really you guys have no issues without rev id? Is there any un-foreseen situations that whole bunch of revs are somehow messed up? How could you know who owns/modifies file? I am a bit old timer, co/ci rcs guy, just started learning the nature of git, can't reach up-to-date technology yet.
With git the whole repo is at a given rev (simplifying this somewhat). There's no concept of individual file revisions, it's the full tree. It's a nuisance to lose the individual file info, but it's less of a nuisance than CVS was IMO. Branching in git far outweighs the inconvenience. I believe there are other ways of checking the version of an exported file, I dunno what they are and likely won't spend much time on it. From a support perspective, it's good enough to have the hash from the build in a version file - that tells us the version of the entire tree on your box (or if the build even came from our official sources - understanding of course the version file itself isn't cryptographically secure).
Please consider to provide a simple txt such as change log kinda style for each snap.
That's unlikely to happen, you can get an RSS feed of the git repo if you care. https://rcs.pfsense.org/projects/pfsense/repos/mainline.atom for all branches or https://rcs.pfsense.org/projects/pfsense/repos/mainline/logs/master/feed.atom for just the master branch (which will eventually be 2.0). Once we have the sha1 stub in the version file, you can easily see yourself what changed between two given sha's (or you can git clone and just do a git log).
–Bill
-
Yes. I agree with billm. It would be very bad to use individual ID's with git. The concept of git just does not make sense with ID's in the file. Instead this would definitely make it much less flexible. If you want to know the ID of a file you better install git on your own and check out the respective version.
